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
You don't understand anything. When we do return, we are entering the On-functions of the generated queue. This may cause a pause which prevents the first OrderSend from sending the correct second one.
What is the pause/delay in? In the copying of 3 structures?
You propose to accumulate the queue by saving all the On-functions after return, waiting for the On-function, which will say that the first OrderSend is finished. And then only send the second OrderSend.
It is not necessary to accumulate all events. Don't wait for the next event to copy - you can process events before return and send the second OrderSend as soon as prerequisites arrive for this
You also do not realize that the take position can be executed during the first OrderSend, but its OnTradeTransaction will be in the queue later (in the same microsecond, but later) than the final OnTradeTransaction from the first OrderSend.
And how does it help you in such a situation?
bool HandleNextEvent(ENUM_EVENT_TYPE);
It will be last here as well as there
You don't understand anything. When we do return, we are entering the On-functions of the generated queue. This may cause a pause which prevents the first OrderSend from sending the correct second one immediately after the first one.
You propose to accumulate the queue by saving all On-functions after return, waiting for the On-function, in which there will be a message about end of the first OrderSend. And then only send the second OrderSend.
At the same time you don't understand that the take position can be executed during the first OrderSend, but its OnTradeTransaction will be in the queue later (in the same microsecond, but later) than the finishing OnTradeTransaction from the first OrderSend.
There is no queue. The new event will be processed after the current one, and all events that occurred during this period will be ignored.
In my opinion, the solution to the problem would be to be able to "subscribe" to an order. That is, for the terminal to generate an event when a transaction on an order occurs.
But this should be implemented by the developers, not by us. All of our solutions, one way or another, will return to the history of deals. I don't have such a microsecond criticality, but it's really
But it is really annoying to write complex bikes to find out if a deal is passed or not passed, if levels are triggered or if someone has corrected a position in the terminal.
Although it would seem a simple thing - an event on a trade on a position - and everything would be much easier.
But it is up to the developers to implement this, not us.
Developers should only provide the tools. MQL is essentially a low-level programming language (just like C++). You use it not in terms of tasks but in terms of calculations. And you make all the high-level decisions by yourself. You may lack tools, but not ready-made solutions
What's the pause\delay? In copying 3 structures?
In processing a queue of diverse events.
How would it help you in such a situation?
It'll be the last one here or there.
I'll be aware of the close on the take.
There is no queue. The new event will be processed after the current event and all events that occurred during this period will be ignored.
Incompetent.
There are various events in the queue to be processed.
I'll be aware of the close on the tee.
Let's stop at the fact that I really (without code withHandleNextEvent ) don't understand elementary things.
As a final note, the difference between the proposedHandleNextEvent and what I wrote is that it's via recursion and I have it via a loop. Besides, the queue is initially formed and you can manage it ... you handle some events at once and postpone them for some other time, you have complete freedom.
At the same time, the same check, sewn into the combat trading advisor on the same Terminal, Alert. What could be the reason?
Forum on trading, automated trading systems and trading strategy testing
MT5 and Speed in Action
Anton, 2020.05.29 16:21
Script for testing of maximum and average time:
2474.
It has become very good. If you have changed it - Thank you. I'll keep an eye on the performance in combat mode.
PS In combat mode, when trades are made, it almost always lags (only outputs cases greater than 5 milliseconds).
Otherwise seems to be much better than 2470.