Función OrderSendAsync() - página 4

[Denis Kirichenko]

Colegas, ¿qué os parece esta idea? En dicha estructura(MqlPacketTradeResult) se puede escribir un campo que indique el número de órdenes completadas, etc.

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

[Yedelkin]

denkir:

Colegas, ¿qué os parece esta idea? En dicha estructura(MqlPacketTradeResult) se puede escribir un campo que indique el número de órdenes completadas , etc.

Pero para hacer esto, tendríamos que esperar una respuesta del servidor dentro de la función OrderSendAsync(). Y la asincronía de la función OrderSendAsync( ) quedará en nada. Renat ya ha prometido que habrá otras funciones que se podrán utilizar para intentar trastear después de que se active OrderSendAsync().

[Denis Kirichenko]

Yedelkin:
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().

Sí, no había pensado en la asincronía...

Eso es todo entonces:

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

bool  OrderReceiveAsync(
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

[Rashid Umarov]

denkir:

Sí, no había pensado en la asincronía...

Bueno, aquí va:

Asíncrono significa trabajar sin esperar una respuesta. Dispara (OrderSenAsync) y ejecuta sin intentar ver si el objetivo es alcanzado. Porque no hay tiempo.

Una respuesta indirecta sería un sonido que llegaría más tarde (OnTrade) - tal vez el disparo dio en el blanco, o tal vez algo se cayó. Aquí es donde puede mirar y ver (comprobar todas las órdenes, operaciones, posiciones, etc.) si lo desea.

[Yedelkin]

denkir:

Sí, no había pensado en la asincronía...

Eso es, entonces:

Bueno, entonces ya OrderSendPacketAsync(), OrderReceivePacketAsync :) Para que siga siendo posible enviar una sola petición en el modo asíncrono ya existente, y buscar información sobre ella después.

[Yedelkin]

Rosh:

Una respuesta indirecta es un sonido que llega después (OnTrade) - tal vez el disparo ha alcanzado el objetivo, o tal vez algo acaba de caer. Aquí es donde puede mirar si lo desea (comprobar todas las órdenes, operaciones, posiciones, etc.).

Por lo tanto, sugiere utilizar en OnTrade() alguna función OrderReceiveXXX() para permitirnos reaccionar no a todos los eventos entrantes de Trade sino sólo a los que pertenecen a colas asíncronas.

[hrenfx]

Rosh:

Asíncrono significa trabajar sin esperar una respuesta. Dispara (OrderSenAsync) y ejecuta sin intentar ver si el objetivo es alcanzado. Porque no hay tiempo.

Una respuesta indirecta es un sonido posterior (OnTrade) - puede ser que el disparo haya dado en el blanco o que algo se haya caído. Aquí es donde puedes mirar si quieres (comprobar todas las órdenes, operaciones, posiciones, etc.).

Te equivocas o bien por tu poca experiencia en el trading en modo asíncrono o bien por la escasa funcionalidad de MT5 para este tipo de operaciones.

No se necesita la asincronía por la asincronía. Y se utiliza sólo cuando es rentable. Por ejemplo, cuando se negocia una cartera, cuando hay que comprar o reequilibrar la cartera aquí y ahora. En otras palabras, una docena de órdenes comerciales para diferentes símbolos a los precios actuales.

Y nadie lo hará, si tratas la asincronía de la forma que has descrito: dispara y olvida. Y las reacciones a los disparos deben evaluarse sobre la base de las posiciones netas actuales. Las reacciones deben ser específicas para cada orden comercial.

Si hubo una redirección, deberían comunicárnoslo, o deberíamos recibir otra respuesta. No debemos preguntarnos si hubo o no una nueva puja, ya que la posición neta no ha cambiado ni un segundo.

En la primera página de esta discusión hay diagramas y eventos de mensajes entrantes. No aparecieron de la nada, sino con años de experiencia asíncrona. Así que vale la pena prestar atención a esa arquitectura sin remilgos.

[Mykola Demko]

denkir:

Colegas, ¿qué os parece esta idea? En dicha estructura(MqlPacketTradeResult) se puede escribir un campo que indique el número de órdenes completadas, etc.

¿Supone que el lote de pedidos tiene siempre los mismos campos?

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

Y lo que supones es sólo una unión del bucle for.

[Denis Kirichenko]

Urain:

¿Está sugiriendo que una pila de solicitudes tiene siempre los mismos campos rellenados?

En mi opinión, un lote de aplicaciones idénticas sólo es necesario para fines de demostración, las aplicaciones con diferentes caracteres, diferentes volúmenes y, por supuesto, diferentes direcciones se utilizarán para el trabajo. Y, en consecuencia, cada solicitante tendrá que ser revisado por separado, por lo que no tiene sentido enviarles un lote.

Y lo que supones es sólo un enlace del bucle for.

¿Y qué le impide rellenar cíclicamente cada uno de los registros ? Y luego, igual de cíclicamente procesar cada resultado?

[Mykola Demko]

denkir:
¿Qué les impide rellenar cíclicamente cada uno de los registros ? Y luego, igual de cíclicamente procesar cada resultado?

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

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

... 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.

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