Asynchronous and multi-threaded programming in MQL - page 25
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I started rereading the topic and Igor had already written about it.
This is what I was trying to say, Yuri, that we need to allocate memory and register the flow.
Igor says you need to allocate and register, while you say you don't need to do anything.
That's why my head is spinning. The result is a deadlock.
Igor studied at university as a specialist, and he should understand more about it than us self-taught fellows.
From the very beginning I was inclined to the same idea - that memory must be allocated and initialized.
Initialization andmemory allocation is the key to correct coding, because it must not flow and must not be rubbish.
So my question to Igor, please explain how to do it in C++?
Not in words, with an example, I don't understand anything ))
BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; }I started to reread the topic and Igor already wrote about it.
That's what I was trying to say, Yuri, that we should allocate memory and register the flow.
I started rereading the thread and Igor had already written about it.
I was initially inclined to the same idea: allocate memory and initialize.
Initialization and memory allocation is the key to correct coding, because it must not drip and have no rubbish.
So my question to Igor, please explain how to do it in C++?
You are masterfully pushing this thread to the top of the discussion, trying to attract more and more participants to your problem ))))
Don't take the correspondence out of context:
- I wrote it in the context that if you want to understand how WinAPI works, you can use ready-made examples on dll writing = over 20 articles on this resource
- I wrote it in a context where you can get to pure WinAPI calls, by replacing plugins that your system programmers have already written for you
....
the point of the correspondence: start to read and do something, not write and write.... You will understand a lot, you will understand what and how works in Windows, but this knowledge will not be in demand, fromyou as from the application programmer only mechanical work - chose the type of project, added your code, compiled = got the result - all the work for you have done hundreds or thousands of system programmers. Any modification of templates and include files must make sense - if you don't know, under the guise of "why so much code, it already works!" - You will get a non-reproducible bug and/or lack of compatibility (portability) with OS/PC
The post is for the creators. Trolls away. For GUIs, it looks good to put the OnChartEvent in a separate thread.
Why break the model the developers made? - The MQL-program model is simple and clear, there are events - there are entry points that process these events (OnTick(),OnInit()....OnChartEvent() )
there is a possibility to obtain the trade environment state from any MQL program (even indicators can see the profit of an open order, etc.) and it is possible to combine Expert Advisor+script, Expert Advisor+user indicator on the same chart - you get asynchronous execution of MQL programs, the EA trades, the indicator displays the graphical visualization - if the performanceof the user indicators stream is not enough (they work in one thread), then of course it is a problem - you need to use 2 EAs on 2 charts and arrange interaction of them
again - there is a specific task, there is an implementation, I have many times asked why this feature is needed, but so far there is no answer - only spatial reasoning about the 3D visualization.... and there's no discussion where to get some DirectX to work with 3D ;)
imho, it works! )))
Why break the model the developers made? - The MQL-program model is simple and clear, there are events - there are entry points that process these events (OnTick(),OnInit()....OnChartEvent() )
there is a possibility to obtain the trade environment state from any MQL program (even indicators can see the profit of an open order, etc.) and it is possible to combine Expert Advisor+script, Expert Advisor+user indicator on the same chart - you get asynchronous execution of MQL programs, the EA trades, the indicator displays the graphical visualization - if the performanceof the user indicators stream is not enough (they work in one thread), then of course it is a problem - you need to use 2 EAs on 2 charts and arrange interaction of them
again - there is a specific task, there is an implementation, I have many times asked why this feature is needed, but so far there is no answer - only spatial reasoning about the 3D visualization.... and there's no discussion where to get some DirectX to work with 3D ;)
imho, it works! )))
Look. There is a button. You click it. The OnChartEvent gets in queue. But in this queue there is already OnTick, and following it there is OnTime, and in them there is CopyRate for all tools, which, for a second, blocks and loops for a shit-ton of iterations. As a result, if the button, for example, should open a dialog window, we get a sluggish interface. Not critical, of course, but not nice.
The GUI should spin in the main EA and everything else in a separate EA. This separate slave EA is placed on invisibleOBJ_CHART and interacts with main EventSendCustom() path.
It gets something like a multithreading. I have implemented it that way.
Look. There is a button. You click it. OnChartEvent gets in the queue. But in this queue there is already OnTick, and following it there is OnTime, and in them there is CopyRate for all tools, which, for a second, blocks and loops for a shit-ton of iterations. As a result, if the button, for example, should open a dialog window, we get a sluggish interface. Not critical, of course, but not nice.
I do not know OnChartEvent OnTick and OnTime, but developers have written that if EA was busy and has not processed the event, this event does not create a queue, i.e. it will be just a tick or timer skip ( OnChartEvent - do not know, did not check)
The developers' logic is simple here, each event is a specific action of the Expert Advisor, but it is this event that I know for sure and have checked more than once (I work more in theory in MT5, I don't know how ONTick physically works):
about MT4 I will say unambiguously: all trade operations should be done only through incoming tick, otherwise in 9 cases out of 10 you will receive server's refusal to process trade operation,
i.e. an interface with the BUY button has been implemented - according to our idea, you press BUY and immediately send an order, but it will not work directly, you need to remember the user command (ideally, block the button so that it does not yak)) and upon tick arrival, in OnTick() - send an order to the server - this will work in 99% of cases, i.e. a tick has come - you can perform a trade request (not from anywhere in MQL)
And if we introduce OnChartEvent into an asynchronous flow, we will get mutual locks of the executed code? - For example, the trade statistics are obtained by pressing the button in OnChartEvent , and the same function (last losing trade) is used in OnTick - it will be something crazy here! - imho, you can't fix it all!
The GUI should spin in the main EA and everything else in a separate EA. This separate slave EA is placed on invisibleOBJ_CHART and interacts with main EventSendCustom() path.
It gets something like a multithreading. I have implemented it that way.
I do not know OnChartEvent OnTick and OnTime, but developers wrote that if EA was busy and has not processed the event, this event does not create a queue, i.e. it will be just a tick or timer skip ( OnChartEvent - do not know, did not check)
The developers' logic is simple here, each event is a specific action of the Expert Advisor, but it is this event that I know for sure and have checked more than once (I work more in theory in MT5, I don't know how ONTick physically works):
about MT4 I will say unambiguously: all trade operations should be done only through incoming tick, otherwise in 9 cases out of 10 you will receive server's refusal to process trade operation,
i.e. I have created an interface with the BUY button - according to my idea, you press BUY and immediately send an order, but it will not work directly, you need to memorize the user command (ideally, block the button so that it does not yak)) and upon arrival of a tick in OnTick() - send an order to the server - this will work in 99% of cases, i.e. a tick has come - you can perform a trade request (not from anywhere in MQL)
And if we introduce OnChartEvent into an asynchronous flow, we will get mutual locks of the executed code? - For example, the trade statistics are obtained by pressing the button in OnChartEvent , and the same function (last losing trade) is used in OnTick - it will be something serious! - imho, you can't fix it all!