Función OrderSendAsync() - página 5

 
Urain:

Si su propuesta sólo complementa una función existente, entonces nada, de lo contrario no está claro cómo una simple estructura MqlPacketTradeRequest ...

... Si la estructura MqlPacketTradeRequest es la estructura del array dinámico de estructuras MqlTradeRequest, puede romper toda la lógica del servidor inundado con estructuras de consulta simples.

De lo contrario, a nivel de terminal, tendríamos que dividir este paquete en peticiones separadas, lo que anularía todo el sentido de introducir esta sobrecarga.

Parece que nos "pusimos de acuerdo" en dicha variante por la estructura asíncrona:

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   );

Dónde,

packet_request incluirá entre otras cosas un array de estructuras MqlTradeRequest...

Entonces todos estos pensamientos son materia prima para la discusión :-)

 
Urain:

IMHO un lote de aplicaciones idénticas es necesario sólo para fines de demostración, para el trabajo se utilizarán aplicaciones de diferentes símbolos, con diferentes volúmenes y por supuesto diferentes direcciones. Y, por lo tanto, cada solicitante tendrá que ser revisado por separado, por lo que no tiene sentido enviarlos en un lote.

Bueno, aquí tienes que elegir: inicio único de la función OrderSendPacketAsync(MqTradeRequest& request[], MqlPacketTradeResult& packet_result) que envía una matriz precargada request[] de 500 elementos a la vez con una comprobación única de código de retorno 10008, o 500 veces iniciando la función OrderSendAsync() con 500 veces comprobando el código de retorno 10008.
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Urain:

...si la estructura MqlPacketTradeRequest es la estructura del array dinámico de estructuras MqlTradeRequest, puede romper toda la lógica del servidor que está diseñado para estructuras de consulta simples.

¿Cómo puede una solicitud de comercio que utiliza una matriz dinámica "romper la lógica del servidor"? Si tengo un bloque que procesa una variable de un determinado tipo de estructura, ¿qué me impide aplicar este bloque a cada elemento de una matriz del mismo tipo? Del mismo modo, si hoy en día un servidor está "orientado a estructuras de consulta simples", ¿qué me impide añadir un bucle, que cuando un servidor acepte un array dinámico enviado por la función OrderSendPacketAsync(), permita aplicar a su vez un bloque "orientado a estructuras de consulta simples" a cada elemento de dicho array?
 
papaklass:

En mi opinión, la función OrderSendAsync() debería hacerse paramétrica en lugar de crear un bucle para el envío de órdenes. Por ejemplo OrderSendAsync(Symbol(), number, direction). Como parámetros: - símbolo, - númerode órdenes, - dirección de las órdenes (compra, venta).

Esto es similar a un caso especial de envío de una solicitud de comercio masivo utilizando una matriz dinámica y la función OrderSendPacketAsync(), cuando los campos"símbolo" y "tipo " son los mismos paracada elemento de la matriz dinámica.
 

Cuando se realizan operaciones asíncronas, no sabemos exactamente cómo se desencadenó una solicitud concreta. En particular, no sabemos qué volumen estaba pendiente cuando una de las peticiones asíncronas se ejecutó parcialmente.

Me pueden decir si he entendido bien que tanto en el comercio de divisas como en el de acciones, la orden de la propiedad de la historia

VOLUMEN_DE_PEDIDO_ACTUAL

Volumen no llenado

nos permite determinar de forma inequívoca el grado de ejecución de una petición asíncrona? Es decir, ¿es correcto que cuando se envía una orden de mercado de forma asíncrona en el mercado de divisas, cuando aparece en el historial, podemos estar seguros de que si ORDER_VOLUME_CURRENT==0,0, la orden se ha ejecutado completamente, pero si ORDER_VOLUME_CURRENT contiene un valor distinto de cero, entonces este valor debe considerarse como el volumen no ejecutado para esa orden de mercado de divisas?

La pregunta viene motivada por el hecho de que aquí: https://www.mql5.com/ru/forum/3775/page28#comment_84851 destaca que la propiedad ORDER_VOLUME_CURRENT se refiere a las órdenes utilizadas en el mercado de valores.

 

Pregunta relativa a la solicitud asíncrona que aparece en el historial.

Cuando OrderSendAsync() devuelve true y el campo result.retcode contiene 10008, entonces, según la Referencia, "significa que la solicitud fue enviada, pero no garantiza que haya llegado al servidor de operaciones".

Pregunta: si una petición asíncrona es enviada con éxito por el terminal, pero no llega al servidor, ¿acabará siempre dicha petición en el historial? En otras palabras, ¿puede ocurrir que una petición asíncrona sea enviada con éxito (según todos los indicios) al servidor, pero que la información sobre ella no aparezca en el historial? Si este escenario es posible, ¿en qué condiciones?

Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:

Pregunta: si una petición asíncrona fue enviada con éxito por el terminal, pero no llegó al servidor, ¿aparecerá siempre la información sobre dicha petición en el historial? En otras palabras, ¿puede ocurrir que una petición asíncrona se envíe al servidor con éxito (en todos los sentidos), pero que la información sobre ella no aparezca en el historial? Si este escenario es posible, ¿en qué condiciones?
Si la petición no llega al servidor, no tiene posibilidad de aparecer en el terminal del cliente.
 
Renat:
Si la petición no llega al servidor, no tiene ninguna posibilidad de aparecer en el terminal del cliente.
¡Uy! Resulta que una petición asíncrona enviada con éxito puede perderse fácilmente y no aparecer en el historial.
Документация по MQL5: Торговые функции / OrderSendAsync
Документация по MQL5: Торговые функции / OrderSendAsync
  • www.mql5.com
Торговые функции / OrderSendAsync - Документация по MQL5
 
Yedelkin:
¡Uy! Resulta que una petición asíncrona enviada con éxito puede perderse fácilmente y no entrar en el historial.
no.
 
Yedelkin:
Resulta que una petición asíncrona enviada con éxito puede perderse fácilmente y no entrar en el historial.

La cuestión es que una petición asíncrona no tiene prácticamente ningún estado de "enviado con éxito".

La finalización exitosa de la función sólo significa que la "orden parece correcta desde el punto de vista del cliente y fue lanzada a la tubería de la red, espere una respuesta en OnTrade".