Organising the order cycle

New comment
 
Comments not related to "mql4 language features, intricacies and tr icks" have been moved to this thread.
 

Continuing the theme of launching MQL5 libraries under MT4

#property strict

// https://www.mql5.com/ru/docs/standardlibrary/graphics/cgraphic
#include <Graphics\Graphic.mqh> // MQL5\Include\Graphics\Graphic.mqh

void OnStart()
{
  double Y[] = {1, 2};
  
  GraphPlot(Y);
}
 

Often in the tester, if the speed slider is set to 31, it's slow, if it's set to 32, the test rushes to its conclusion with super speed.

I get out of it by inserting a delay through the counter into the code:

input int gDelay = 10000;        // Счетчик для задержки, off=0

void OnTick()
{
  int delayCount = 0;
  while(delayCount < gDelay) ++delayCount;
}

The delay via input can be adjusted depending on the speed of the EA and processor power.

At speed 32 I can now move to the points of interest at a speed that suits me.

 

Below we will be touching on a subject which not only concerns MT4, but also MT5 with other platforms. But the logic will be written in MQL4 for easy perception, so in this branch.


Most often the backbone (the meat of any order) of order modification/deletion comes down to the following logic

// Самый распространенный костяк логики модификации ордеров
for (int i = OrdersTotal() - 1; i >= 0; i--)
  if (OrderSelect(i, SELECT_BY_POS))
    OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration());


Now, the approach is rare, but much more correct

// Редкий, но правильный костяк модификации ордеров
for (int i = OrdersTotal() - 1; i >= 0; i--)
  if (OrderSelect(i, SELECT_BY_POS))
    if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration()))     
    {
      i = OrdersTotal(); // Хотя бы так
      
      // А лучше так
//      OnTick(); break; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно)
    }


After sending a trade order, the trade environment changes, so it is advisable to execute the entire trading logic of the TS from scratch immediately after the trade server replies.

 
fxsaber:

Now the approach is rare, but much more correct

This variant hooks on modifying the last order in the list at any error, and the Expert Advisor that has more than 1 order "loses sight" of all the others.

My recipe: loop through all of its orders, process each of them (updating the market information before processing them, if necessary), and on the next tick, the next approach. In some cases, the next approach (OnTick call) may be done immediately after the current loop has finished, if there have been errors in it.

 
Andrey Khatimlianskii:

This option loops on the modification of the last order in the list when there is any error, and an EA with more than 1 order "loses sight" of all the others.

There will be no looping because of this condition

if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration()))

My prescription: loop through all of your orders, process each of them (update the market information before processing them, if necessary) and on the next tick, the next approach. In some cases, the next approach (OnTick call) can be made right after the current loop ends if there were errors in it.

Then more errors of trade requests can be seen in the terminal log.

 
fxsaber:

There will be no looping because of this condition

Yes, wrong, read it as !OrderModify.

If the modification is successful, the processing cannot be repeated from the beginning of the list either, because in this case one order will also be modified (e.g. pulled up behind the price), and the others may be left unattended for a long time.

My recipe is still valid.


fxsaber:

Then the terminal log will show more trade request errors.

I didn't get that one.

 
Andrey Khatimlianskii:

If the modification is successful, the processing cannot be repeated from the beginning of the list either, because in this case one order will also be modified (e.g. pulling up behind the price), and the others may be left unattended for a long time.

There is something wrong in this logic from the very beginning. We must make a conscious choice: it is better to have one actual order or many irrelevant ones.

My recipe is still valid.

I didn't get this one.

Let the OrderModify run for 5 seconds. During its execution, let a partial limit order be executed several times on the trade server, generating a dozen trades.

 
fxsaber:

Something in this logic is wrong from the beginning. You have to make a conscious choice: Better one actual order or many irrelevant ones.

One order cannot be at different levels at the same time. Or should we have a different EA for each level? This is a questionable solution for the vast majority of strategies.

As a special case, several positions (gained by trend with several entries) and a trailing stop for them. Pull the SL of just one trade, or modify all of them? On a sharp movement with the same sharp subsequent rollback, the option to modify only one order will lose much (and we won't get to the rest, because each new call to OnTick will modify the very first order in the list).


fxsaber:

Let OrderModify run for 5 seconds. During its execution, let's assume that a partial limit order has been executed several times on the trade server, having generated a dozen of deals.

Suppose that. We will process all orders that were (and should be) executed, and pass to the new ones on the next tick or directly after the first cycle.

Otherwise we always risk working with one - the last - executed part of one last order. Perhaps the smallest part. Leaving a large order hanging there unattended.

 
Andrey Khatimlianskii:

One order cannot be at different levels at the same time. Or should we have a different EA for each level? This is a questionable solution for the vast majority of strategies.

As a special case, several positions (gained by trend with several entries) and a trailing stop for them. Pull the SL of just one trade, or modify all of them? If we have a sharp move with an equally sharp subsequent pullback, the option to modify only one order would lose a lot (and we won't reach the rest, because each new call to OnTick will modify the very first order in the list).

I don't understand why OnTick would modify only one order? All of them will be modified.

Let's say. We will process all the orders that were (and should be) processed and move on to the new ones at the next tick or immediately after the first cycle.

Otherwise we will always risk working with one - the last - executed part of one last order. Perhaps the smallest part. Leaving a large order hanging there unattended.

I draw attention to the word "backbone". The meat in the form of lot priority selection or something else can always be built up. The core logic, on the other hand, remains the same: after a successful trade order, run the entire trading logic from scratch.

 
fxsaber:

I don't understand why OnTick will modify only one order? All will be modified.

Because the price will move, and on each new call to OnTick, the condition for a new modification of the same, first in the list, order will be fulfilled. Especially if the modification will last 5 seconds ;)


fxsaber:

Note the word "backbone". The meat in the form of lot priority selection or something else can always be added. The core logic, on the other hand, remains the same: after a successful trade order, run all the trade logic from scratch.

Such a "backbone" would break the logic of an EA working with more than one order.
What is the point in it if it will not give any advantage to systems with one order and will spoil the others?

Sorting by volume and/or distance from price before working with orders is a good solution. But we shouldn't assume that everyone who copies the code from the forum will implement it.
In that sense, my code is safer.

123456789101112131415
New comment
Reason: