Features of the mql4 language, subtleties and techniques - page 35

New comment
 
fxsaber #:

So now I'm wondering how to go through ALL the orders at ONE time.

I'm not sure what to do, but I'm trying to write it in such a way that such slippages do not lead to critical consequences.

The probability will decrease, but minus the diversification and complication of account management.

 
Andrei Trukhanovich #:

Alternatively, spread the bots across different accounts.

Then prohibit, for example, the expiration of the put-away orders. In general, a crutch.

A fundamental necessity with such an unfortunate peculiarity. Apparently, to do it through snapshots somehow.

 
fxsaber #:

Thanks for the detailed reply! Now I'm wondering how to go through ALL orders at ONE time.

How about remembering the first and last order ( ticket )?

and after the cycle is complete, check that the first and last order have the same tickets as before the count

   int n  = OrdersTotal();
   
   if(n == 0) return(0.0);
   else if(n == 1 && OrderSelect(0, SELECT_BY_POS)) return(OrderLots());
   
   int t_last = OrderSelect(n - 1, SELECT_BY_POS) ? OrderTicket() : -1;
   int t_first = OrderSelect(0, SELECT_BY_POS) ? OrderTicket() : -1;


SZY: quite logically, OrderSelect() should be responsible for this collision - it should return false in case the table of orders has changed, but I cannot recall reading anywhere on the forum that OrderSelect() has returned false, I have not encountered error handlers for OrderSelect() either.

 
Igor Makanu #:

can remember the first and last order (ticket)?

Without a complete memorisation of the ticket sequence, such a solution will fail.

 
fxsaber #:

If you don't remember the sequence of tickets completely, this solution will fail.

And full saving of tickets will also cause failures because while we are running through a loop, the state of orders that have already been processed may change


of course, I am not sure, but if an order is closed when we are in the cycle, the OrderTotal() will change

if the order is closed and a new order opens, then the ticket and/or OrderSelect(0) or OrderSelect(OrderTotal()-1) will be changed


and in your opinion, what situation could happen, so that the previous "extreme orders" and the OrderTotal() itself remain?

 
Igor Makanu #:

and in your opinion, what situation could happen to keep the same "extreme orders" and the OrderTotal() itself ?

Most likely, the OrdersTotal will change when the order table is shaken up.

And then it's possible that the limiters will be refilled and an additional position will be created.

 
Igor Makanu #:

can we memorise the first and last order (ticket)?

remembering the first one does nothing

 
fxsaber the function was called? Or will it count twice.

I.e. what happens to the indexing when an order is deleted or appears during the enumeration?

I collect an array of tickets and work with it.
If OrdersTotal or Balance or Margin has changed - then the list has to be re-created.

So EA always works only with its own selected tickets

 
Andrei Trukhanovich #:

remembering the first one does not do anything

these are peculiarities of the architecture implementation, which are not documented and no one can guarantee in the future...

Note OrderTotal() andOrdersHistoryTotal(), and the tickets of the last orders

if these values change after the calculations in the loop, then process


But there can be no universal and reliable solution - the task here is to guess what will happen on the server, how the data is delivered via the network, and what is going on in the adjacent charts in the terminal ))))


The only thing to hope for is the speed of OrderSelect() - if I remember correctly, it's more than a million calls per second

 
fxsaber #:

Without a complete memory of the ticketing sequence, such a solution will fail.

It may not be expensive to remember, but it may be expensive to keep track of full status. I agree with the previous ones, reduce the load by logic of reasonableness and priorities.

The asynchronous world we live in does not guarantee the order of responses to the order of requests, nor does it guarantee order at all.
1...282930313233343536
New comment