Preguntas de OrderSend() - página 8

 

Mientras esperamos un artículo sobre este tema, ¿he entendido bien el concepto general de análisis de operaciones comerciales?

...
bool AllowTrade = true;
ulong OrderTicket;
...
void OnTick() {
  ...
  if (!AllowTrade) return;
  ...
  MqlTradeResult Result;
  if (OrderSend(...)) {
    Ticket = Result.order;
    AllowTrade = false;
  }
}
...
void OnTrade() {
  if (AllowTrade) return;
  if (OrderSelect(Ticket)) {
    if (...)
    ...
    // AllowTrade = true|false;
  }
  else AllowTrade = true;
}
...

Es decir, a grandes rasgos, después de enviar una orden sin analizar el retcode, prohibimos las operaciones de trading en el bucle de trabajo (OnTick()) utilizando el flag "AllowTrade".

La prohibición de comercio sólo se desbloquea en OnTrade() después de encontrar el número de orden y de analizar su destino.

Tenemos dos preguntas:

1. ¿Qué es el ticket de pedido que hay que comprobar en OnTrade? ¿Qué estados son definitivos en su vida?

2. Sé que la cola de eventos Tick (OnTick) puede "caer". Es decir, si llega otro evento Tick y la función OnTick (del Tick anterior) aún no ha terminado su trabajo, el evento actual será "descartado", es decir, no será procesado. ¿Existe un enfoque similar con los eventos comerciales (OnTrade)? Es decir, ¿es posible que, por ejemplo, en el bucle principal ponga una prohibición de comercio y el evento OnTrade de la orden recién enviada "caiga", porque en el momento de su llegada todavía estaré procesando algo en el mismo tick que el envío de la orden de comercio correspondiente?

 
voix_kas: Es decir, ¿hay alguna probabilidad de que, por ejemplo, coloque una prohibición de comercio en el bucle principal y el evento OnTrade de la orden que se acaba de enviar "se caiga", ya que para cuando llegue, todavía estaré procesando algo en el mismo tick que el envío de la orden de comercio correspondiente?

No he tratado este tema, pero esto es lo que dice el Manual:

1) La longitud de la cola de transacciones es de 1024 elementos. Si OnTradeTransaction() tarda demasiado en procesar otra transacción, las transacciones antiguas en la cola pueden ser sustituidas por otras más nuevas;

2) Se llama a OnTrade después de las correspondientes llamadas a OnTradeTransaction.

 
Yedelkin:

No he tratado este tema, pero esto es lo que dice el Manual:

1) La longitud de la cola de transacciones es de 1024 elementos. Si OnTradeTransaction() tarda demasiado en procesar otra transacción, las transacciones antiguas en la cola pueden ser sustituidas por otras más nuevas;

2) Se llama a OnTrade después de las correspondientes llamadas a OnTradeTransaction.

Generalmente se entiende. Como ya señalópapaklass y dijo en el artículohttps://www.mql5.com/ru/articles/232:

Sólo hay una forma garantizada de saber exactamente qué ha cambiado en una cuenta comercial. Esta forma es para recordar el estado del comercio y el historial de comercio y comparar el nuevo estado con el guardado.

Un bloque de servicio más en el Asesor Experto. :(

En realidad, la pregunta es la siguiente. ¿Podemos reducir el tamaño del código sin analizar todas las variables (órdenes/operaciones/posiciones), y centrarnos sólo en el número de orden obtenido del resultado de OrderSend? ¿O este número puede ser no único/no reflejado en el historial?

 
voix_kas: ¿Podemos reducir el tamaño del código sin analizar todas las variables (órdenes/operaciones/posiciones), y centrarnos sólo en la orden cuyo número se obtiene del resultado del OrderSend? ¿O este número puede ser no único/no reflejado en el historial?

Por supuesto. Si una solicitud de negociación ha dado lugar a la recepción de un ticket de orden, este ticket es único, y a través de él se puede seguir todo el destino de la orden.

Aquí puede ver cómo se utiliza el ticket de pedido en el historial: MQL5 Reference / Trading Functions / HistoryOrderGetInteger

 
Yedelkin:
Por supuesto. Si una solicitud de negociación ha dado lugar a un ticket de orden, ese ticket es único y puede utilizarse para seguir todo el destino de la orden.
Sólo para información. En caso de que la orden no haya sido aceptada por el servidor para su ejecución, por ejemplo, una recotización, ¿se asigna a la variable MqlTradeResult.order un valor por defecto (por ejemplo, "0")?
 
voix_kas: En caso de que una orden no haya sido aceptada por el servidor para su ejecución, por ejemplo, una recotización, ¿se asigna a la variable MqlTradeResult Resultado.orden algún valor por defecto (por ejemplo, "0")?
Una variable de tipo MqlTradeResult suele ponerse a cero antes de ser utilizada. Por lo tanto, el campo Result.order contiene un valor cero. Nunca he visto que este campo tome un valor diferente tras el envío fallido de una solicitud de intercambio.
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:
Una variable de tipo MqlTradeResult suele ponerse a cero antes de ser utilizada. Así que el campo Result.order contiene un valor cero. Nunca he visto que este campo tome un valor diferente después de un envío infructuoso de la solicitud de comercio.
Si no le importa, me gustaría profundizar en la cuestión de la interpretación de los códigos de devolución. 24 de las 30 respuestas declaradas (esperemos que no nos encontremos con las no declaradas) indican claramente un fallo en la realización del pedido. Los otros 6: 1. TRADE_RETCODE_PLACED Supongamos que no colocamos órdenes pendientes. ¿Es posible esta respuesta en el comercio de mercado (SYMBOL_TRADE_EXECUTION_MARKET)? 2. TRADE_RETCODE_DONE No se puede comprobar nada más. Todo fue exactamente como lo describe el Asesor Experto. 3. TRADE_RETCODE_DONE_PARTIAL Supongo que esta respuesta es similar a TRADE_RETCODE_DONE dado el modo ORDER_FILLING_IOC, si se opera sin órdenes pendientes. 4. TRADE_RETCODE_ORDER_CHANGED ¿Significa esto un rechazo inequívoco de nuestra orden comercial? 5. TRADE_RETCODE_LOCKED Creo que este es el peor caso. ¿Qué debemos hacer en este caso? Sugiero que el número de pedido no esté disponible todavía. El flujo comercial está ocupado. No podemos comerciar y no está claro cómo podemos saber que el flujo comercial está desbloqueado. 6. TRADE_RETCODE_FROZEN ¿Significa esto un rechazo inequívoco de nuestra orden comercial? Por favor, comente cada punto.
 

voix_kas: Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:  

1. TRADE_RETCODE_PLACED Supone que no hay órdenes pendientes. ¿Es posible esta respuesta durante las operaciones de mercado (SYMBOL_TRADE_EXECUTION_MARKET)?

TRADE_RETCODE_DONE No se puede comprobar nada más. Todo fue exactamente como lo pidió el Asesor Experto.

3. TRADE_RETCODE_DONE_PARTIAL Supongo que esta respuesta es la misma que TRADE_RETCODE_DONE dado el modo ORDER_FILLING_IOC.

4. TRADE_RETCODE_ORDER_CHANGED ¿Significa esto un rechazo inequívoco de nuestra orden comercial?

5. TRADE_RETCODE_LOCKED Creo que este es el peor caso. ¿Qué debemos hacer en este caso? Sugiero que el número de pedido no esté disponible todavía. El flujo comercial está ocupado. No podemos comerciar, y no está claro cómo debemos saber si el flujo comercial está desbloqueado o no.

6. TRADE_RETCODE_FROZEN ¿Significa esto un rechazo inequívoco de nuestra orden comercial?

Por favor, comente cada punto.

Lamentablemente, mis conocimientos no son suficientes para hacer un comentario completo sobre cada punto. Si pasa algo, mis colegas lo corregirán.

1. En el foro se mencionó una vez una situación en la que se puede abrir una cuenta comercial con un subcorredor. En este caso, el subcorredor puede enviar la solicitud de operación para su posterior procesamiento (al corredor) y enviar TRADE_RETCODE_PLACED al terminal del cliente. Se desconoce si el corredor acabará tramitando dicha solicitud de negociación.

2. Sí, yo también lo creo. Lo único que debemos recordar es que la información sobre esta orden se recibirá en la base de datos del terminal de forma asíncrona.

Creo que estamos hablando de la ejecución parcial de una solicitud de operación en los modos ORDER_FILLING_IOC y ORDER_FILLING_RETURN.

4. https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. No sé absolutamente nada de este código. Técnicamente, resulta que la solicitud no fue procesada debido a algunas razones internas del corredor. No está claro si se procesará más tarde. Yo mismo equiparo este código al rechazo de una solicitud de comercio.

6. https://www.mql5.com/ru/forum/1111/page123#comment_18372

... Y en general - intente una búsqueda de palabras clave en el foro. Puedes encontrar mucha más información :)

 
Yedelkin:

Desgraciadamente, no tengo suficientes conocimientos para comentar a fondo cada uno de los puntos. En todo caso, los colegas lo corregirán.

1. En el foro se mencionó una vez una situación en la que se puede abrir una cuenta comercial con un subcorredor. En este caso, el subcorredor puede enviar la solicitud de operación para su posterior procesamiento (al corredor) y enviar TRADE_RETCODE_PLACED al terminal del cliente. Se desconoce si el corredor acabará tramitando dicha solicitud de negociación.

2. Sí, yo también lo creo. Lo único que debemos recordar es que la información sobre esta orden se recibirá en la base de datos del terminal de forma asíncrona.

Creo que estamos hablando de la ejecución parcial de una solicitud de operación en los modos ORDER_FILLING_IOC y ORDER_FILLING_RETURN.

4. https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. No sé absolutamente nada de este código. Técnicamente, resulta que la solicitud no fue procesada debido a algunas razones internas del corredor. No está claro si se procesará más tarde. Yo mismo equiparo este código al rechazo de una solicitud de comercio.

6. https://www.mql5.com/ru/forum/1111/page123#comment_18372

... Y en general - intente una búsqueda de palabras clave en el foro. Puedes encontrar mucha más información :).

Aquí tenemos lo siguiente: 26 de los 30 códigos (incluyendo TRADE_RETCODE_ORDER_CHANGED y TRADE_RETCODE_FROZEN) representan el rechazo explícito de la solicitud (no genera una orden).

TRADE_RETCODE_DONE y TRADE_RETCODE_DONE_PARTIAL - orden creada garantizada.

Cómo ejecutar correctamente TRADE_RETCODE_PLACED (no pendiente) y TRADE_RETCODE_LOCKED es una pregunta. Se agradecerían los comentarios de MQ sobre estos dos códigos.

 
Que guay, Feliz Año Nuevo #2015 a todos, pero me pregunto cómo acabó. Han sido dos años de silencio....