Make a certification service for programmers ... - page 6

 

Yeah guys....

already grading is up for grabs :))))

 
VOLDEMAR:
If you have nothing good to say, don't say anything or at least talk about it ..... If you knew something, you'd show me... Or is it too bad? Or don't know anything ....?

there is nothing to argue about.

You'd actually be better off combing your order sending functions for the correctness of the order being sent to the server.

I do not want the error to be reported before the server, but before...)
Документация по MQL5: Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции
Документация по MQL5: Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции
  • www.mql5.com
Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции - Документация по MQL5
 
MrGold166:
That's the point of the overshooting from the end, there is nothing military about processing one order twice. In the worst case it only prevents us if we count orders, for example the average price, one order will be counted 2 times. Even if it strongly interferes with the calculations, on the next tick everything will fall back into place and we will put the take profit where it should be. In my memory with more than 50 orders and with the worst so-called Asian "broker" (yes, you know who I mean) this has never happened after the account was traded (you know why). But this too can be avoided:

int i,last_ticket;
for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {
   if(OrderTicket()==last_ticket) continue;
   last_ticket=OrderTicket();
   }

And how can you guarantee that you won't get the same situation the next time you tick, yes nothing.

And the worst case may come, you will calculate the average wrong and open an order wrong and the next tick will not matter.

It is not the number of orders that matters, but the trading environment, the presence of real stops, the presence of other EAs in the account.

 
MrGold166:
But this too can be avoided:

int i,last_ticket;
for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {
   if(OrderTicket()==last_ticket) continue;
   last_ticket=OrderTicket();
   }
Theoretically more than one order could change state
 
A100:
Theoretically the state of more than one order could change

A sound idea, I didn't think of two, got hung up on one.

So back to square one, so how to solve collisions with this function.

 
sandex:

Sound idea, I didn't think of two, got stuck on one.

So back to square one, so how to solve collisions with this function.

   int j=OrdersTotal();
   for(int i=j-1;i>=0;i--)
   {
      if(OrderSelect(i,SELECT_BY_POS))
      {
      }
   }
   if(j!=OrdersTotal())return(0);

If anything, recalculate again. if the number of entry and exit orders are not equal.

 
A100:
Theoretically more than one order could change

So what? Even if everyone changes, we still won't analyse the same trades.

If we are talking about a trade up the list that has changed, then it may change after we have gone through the search - before we put the total profit.

 
snowman:

If anything, recalculate again if the number of entry and exit orders is not equal.

In general case even the number of orders can be equal, only they can be different orders
 
snowman:

If the number of orders at entry and exit is not equal, then recalculate it again.

This will also not help us if a pending order is opened, the amount of orders will be saved but the parameters will not. On the other hand, this would hardly disturb us, if we hadn't included a newly opened pending order into the amount, that's OK. (I really do not see a situation, in which this can cause an error). This situation may only occur under a special set of circumstances, one of which is a lot of ticks, i.e. the next iteration will be very soon and the error will be corrected. In case the order rebound happens between ticks, this is not a problem for us.

We often see other programmers' codes where the enumeration is done dozens of times per iteration separately to calculate a heap of parameters and this is a problem.

 
MrGold166:

So what? Even if everyone changes, we still won't analyse the same trades.

If we are talking about a trade up the list that has changed, then it may change after we have gone through the search - before we put the total profit.

I wasn't referring to the calculation as applied to a specific situation, but to the general case. I think double counting and/or undercounting does matter, sometimes critically
Reason: