Organizar el ciclo de pedidos

 
Los comentarios que no están relacionados con "Características, complejidades y trucos del lenguaje mql4" han sido trasladados a este hilo.
 

Siguiendo con el tema del lanzamiento de las librerías MQL5 bajo 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);
}
 

A menudo, en el probador, si el control deslizante de la velocidad está ajustado a 31, es lento, si está ajustado a 32, la prueba se precipita a su conclusión con supervelocidad.

Salgo de esto insertando un retraso a través del contador en el código:

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

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

El retardo a través de la entrada puede ajustarse en función de la velocidad del EA y de la potencia del procesador.

A la velocidad 32, ahora puedo desplazarme a los puntos de interés a la velocidad que me convenga.

 

A continuación vamos a tocar un tema que no sólo afecta a MT4, sino también a MT5 con otras plataformas. Pero la lógica se escribirá en MQL4 para facilitar la percepción, por lo que en esta rama.


La mayoría de las veces la columna vertebral (la carne de cualquier orden) de la modificación/eliminación de órdenes se reduce a la siguiente lógica

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


Ahora, el enfoque es raro, pero mucho más correcto

// Редкий, но правильный костяк модификации ордеров
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; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно)
    }


Después de enviar una orden comercial, el entorno comercial cambia, por lo que es aconsejable ejecutar toda la lógica comercial del ST desde cero inmediatamente después de que el servidor comercial responda.

 
fxsaber:

Ahora el enfoque es raro, pero mucho más correcto

Esta variante se engancha a modificar la última orden de la lista en cualquier error, y el Asesor Experto que tiene más de 1 orden "pierde de vista" todas las demás.

Mi receta: hacer un bucle con todas sus órdenes, procesar cada una de ellas (actualizando la información del mercado antes de procesarlas, si es necesario), y en el siguiente tick, el siguiente planteamiento. En algunos casos, la siguiente aproximación (llamada OnTick) puede hacerse inmediatamente después de que el bucle actual haya terminado, si ha habido errores en él.

 
Andrey Khatimlianskii:

Esta opción hace un bucle en la modificación de la última orden de la lista cuando hay algún error, y un EA con más de 1 orden "pierde de vista" todas las demás.

No habrá ningún bucle debido a esta condición

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

Mi prescripción: hacer un bucle con todas sus órdenes, procesar cada una de ellas (actualizando la información del mercado antes de procesarlas, si es necesario) y en el siguiente tick, el siguiente planteamiento. En algunos casos, la siguiente aproximación (llamada OnTick) puede hacerse justo después de que el bucle actual termine si hubo errores en él.

Luego se pueden ver más errores de solicitudes de comercio en el registro de la terminal.

 
fxsaber:

No habrá ningún bucle debido a esta condición

Sí, es un error, léalo como "OrderModify".

Si la modificación tiene éxito, tampoco se puede repetir el proceso desde el principio de la lista, porque en este caso también se modificará una orden (por ejemplo, se subirá detrás del precio) y las demás pueden quedar desatendidas durante mucho tiempo.

Mi receta sigue siendo válida.


fxsaber:

Entonces el registro de la terminal mostrará más errores de solicitud de comercio.

No lo entendí.

 
Andrey Khatimlianskii:

Si la modificación tiene éxito, tampoco se puede repetir el proceso desde el principio de la lista, porque en este caso también se modificará una orden (por ejemplo, tirando por detrás del precio), y las demás pueden quedar desatendidas durante mucho tiempo.

Hay algo que falla en esta lógica desde el principio. Debemos hacer una elección consciente: es mejor tener una orden real o muchas irrelevantes.

Mi receta sigue siendo válida.

No entendí esto.

Deje que el OrderModify se ejecute durante 5 segundos. Durante su ejecución, deja que una orden limitada parcial se ejecute varias veces en el servidor de operaciones, generando una docena de operaciones.

 
fxsaber:

Algo en esta lógica está mal desde el principio. Tienes que hacer una elección consciente: mejor un pedido real o muchos irrelevantes.

Una orden no puede estar en diferentes niveles al mismo tiempo. ¿O deberíamos tener un EA diferente para cada nivel? Esta es una solución cuestionable para la gran mayoría de las estrategias.

Como caso especial, varias posiciones (ganadas por tendencia con varias entradas) y un trailing stop para ellas. ¿Tirar el SL de una sola operación, o modificar todas? En un movimiento brusco con el mismo retroceso brusco posterior, la opción de modificar sólo una orden perderá mucho (y no llegaremos al resto, porque cada nueva llamada a OnTick modificará la primera orden de la lista).


fxsaber:

Deje que OrderModify se ejecute durante 5 segundos. Durante su ejecución, supongamos que una orden limitada parcial se ha ejecutado varias veces en el servidor de operaciones, habiendo generado una docena de operaciones.

Supongamos que. Procesaremos todas las órdenes que fueron (y deben ser) ejecutadas, y pasaremos a las nuevas en el siguiente tick o directamente después del primer ciclo.

De lo contrario, siempre nos arriesgamos a trabajar con una -la última- parte ejecutada de una última orden. Quizás la parte más pequeña. Dejando un gran pedido colgado sin atender.

 
Andrey Khatimlianskii:

Una orden no puede estar en diferentes niveles al mismo tiempo. ¿O deberíamos tener un EA diferente para cada nivel? Esta es una solución cuestionable para la gran mayoría de las estrategias.

Como caso especial, varias posiciones (ganadas por tendencia con varias entradas) y un trailing stop para ellas. ¿Tirar el SL de una sola operación, o modificar todas? Si tenemos un movimiento brusco con un pullback posterior igualmente brusco, la opción de modificar sólo una orden perdería mucho (y no llegaríamos al resto, porque cada nueva llamada a OnTick modificaría la primera orden de la lista).

No entiendo por qué OnTick modificaría sólo una orden? Todos ellos serán modificados.

Digamos. Procesaremos todos los pedidos que fueron (y deben ser) procesados y pasaremos a los nuevos en el siguiente tick o inmediatamente después del primer ciclo.

De lo contrario, siempre nos arriesgaremos a trabajar con una -la última- parte ejecutada de una última orden. Quizás la parte más pequeña. Dejando un gran pedido colgado sin atender.

Llamo la atención sobre la palabra "columna vertebral". La carne en forma de selección de la prioridad del lote o algo más siempre se puede construir. Por otro lado, la lógica central sigue siendo la misma: después de una orden de negociación exitosa, ejecuta toda la lógica de negociación desde cero.

 
fxsaber:

No entiendo por qué OnTick modificará sólo una orden? Todo será modificado.

Porque el precio se moverá, y en cada nueva llamada a OnTick, se cumplirá la condición de una nueva modificación de la misma orden, la primera de la lista. Sobre todo si la modificación dura 5 segundos ;)


fxsaber:

Fíjate en la palabra "columna vertebral". Siempre se puede añadir la carne en forma de selección de prioridad de lote o algo más. Por otro lado, la lógica central sigue siendo la misma: después de una orden de operación exitosa, ejecuta toda la lógica de la operación desde cero.

Esta "columna vertebral" rompería la lógica de un EA que trabaja con más de una orden.
¿Qué sentido tiene si no va a dar ninguna ventaja a los sistemas con un orden y va a estropear los otros?

Clasificar por volumen y/o distancia del precio antes de trabajar con los pedidos es una buena solución. Pero no debemos asumir que todos los que copien el código del foro lo aplicarán.
En ese sentido, mi código es más seguro.

Razón de la queja: