Learning and writing together in MQL5 - page 26
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
From the Handbook:
Все возникающие события клиентский терминал складывает в общую очередь.
...The event queue has a limited size.
So is anyone going to help me or not? On page 25, two councillors...
Scolding is scolding. Now help me understand. You accused me of not giving you enough data to analyse the problem. I don't need any more. You can check whatever you want.
I guess everyone's testing my robots... I'll wait. Probably need to hire a programmer for money to help find a bug.
By the way, does anyone else remember what the thread topic is called....?
From the Handbook:
There has been some discussion about the event queue, but I couldn't find the exact size. How deep is the event queue? 64? 256? ...events?
I also wanted to ask what will happen if the event queue starts to accumulate and choke? will new events be ignored or will those already in the queue be reset? and of course when will this happen (at which event in the queue)?
already answered
https://www.mql5.com/ru/forum/1621/43941#comment_43941
already answered
https://www.mql5.com/ru/forum/1621/43941#comment_43941
I think clarification is still needed, there's an answer but it's blurred, my questions aren't even hinted at.
Neither exact indication of queue length, nor which events will be skipped (what do you mean "part of events will be skipped"?) what part?, new events or those already in queue? logic is powerless here, as new events may be more important than those in queue, or vice versa.
So it's better to clarify this point.
So is anyone going to help me or not? On page 25, two councillors...
Scolding is scolding. Now help me understand. You accused me of not giving you enough data to analyse the problem. I don't need any more. You can check whatever you want.
I guess everyone's testing my robots... I'll wait. Probably need to hire a programmer for money to help find a bug.
By the way, does anyone else remember what the thread topic is called....?
You have a slippage of 50 in mql4 and 10 in mql5. Try to set the same slippage, maybe the situation will even out because a lot of orders with such a slippage may just get into requotes.
Better yet, in both variants set slippage to the spread size.
I will repeat the question:
How do I correctly delete all orders with a certain magik?
...I need to go through the list of orders from top to bottom, for example like this:
I tried doing as you said, but the problem remains - the pending order is deleted first, then another request is sent to delete the same order. Here is an example of the log lines:
2011.05.12 16:42:57 Traes '726238' : cancel order #4388299 buy stop 0.02 EURUSD at 1.41700 done - order successfully deleted
2011.05.12 16:42:57 Trades '726238' : cancel order #4388299 buy stop 0.02 EURUSD at 1.41700 - Another request is being sent
2011.05.12 16:42:58 Trades '726238' : failed cancel order #4388299 buy 0.00 at 0.00000 [Invalid request] - it was buy for some reason.
This does not happen every time, but sometimes, and it does not affect the Expert Advisor's operation. I just want to make everything right, not to load the trade server with empty requests and to understand the problem.
Thank you for your replies and your willingness to help.
-----------------
I will try to give my opinion. To delete an order with a certain magic number or any other one does not change the matter, as well as to scroll through the orders lengthwise or crosswise. You can memorize an order and then delete it by ticket, the error will occasionally pop up.
As I imagine, the server has indeed deleted the order, as evidenced by the message in the log and in the server's retcode response. But the terminal does not know about it yet, i.e. the order is still working for it (or it knows it but it gives outdated information to the EA, though it would have failed the check then) and on the next tick it sends another request to delete it and get an error from the server.
The fact that the server has turned a buy stop order into a simple buy order, seems to be a mistake of the server: it does not distinguish these orders in case of a request error. This is something for the developers to remember.
How can we avoid repeated requests ? I think there are only two ways:
1. After successful deletion, analyse the last history, waiting for the deleted order to appear in it, then continue.
2. simply introduce a delay, say two seconds, after the deletion is done. One second might not be enough.
I would also like to add that this situation happens not only with pending orders, but also with market orders, as well as with positions when they are changed. This happens rather rarely and may be noticed only when trading on a demo account for a long time, but in the tester, of course, it does not show up. Also, after changing a position, it happens that the margin level that existed before the change is reversed, probably other account parameters as well, I have not checked.
У вас в mql4 стоит проскальзывание 50, а в mql5 10. Попробуйте поставить одинаковое проскальзывание возможно ситуация выровняется тк много приказов с таким слипажем может просто попадать на реквот.
And better yet, in both variants, set the slippage tothe size of the spread.
I'll try that, but it's unlikely the situation will improve manifold.
Do I have problems in programming or everything is fine?
I think clarification is still needed, there is an answer but it's blurred, my questions aren't even hinted at.
Neither exact indication of queue length, nor which events will be skipped (what do you mean "part of events will be skipped"?) what part?, new events or those already in queue? logic is powerless here, because maybe new events may be more important than those in queue, and maybe vice versa.
So it's better to clarify this point.
1)"stacks in common queue" - mistake in documentation. There are actually many queues. At present, every mql5 program and every chart has its own queues. The sizes of the queues are different and are not small in general, overflow of the queue is unlikely for a correctly written program. We will not document the exact size of each queue, their number, or any other detailed description of the internal implementation. The reason is quite obvious - the internal implementation can change.
2) Any new events, for which there is not enough space in this particular queue, will be skipped.
Let me remind you that the events of a new tick and change of a chart can exist only in a single instance in the incoming events queue of the mql5 program. Generation of events of creation and deletion of graphical objects on a chart can be enabled/disabled.
Can you tell me what those green bars at the bottom mean? In MT4 they meant lot volume and were drawn when the lot changed. But what is it for here? Or my lot volume changes? It seems I do not change it.