![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
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:
Dónde,
packet_request incluirá entre otras cosas un array de estructuras MqlTradeRequest...
Entonces todos estos pensamientos son materia prima para la discusión :-)
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.
...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.
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).
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
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?
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 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 entrar en el historial.
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".