Función OrderSendAsync() - página 7

 

Asincronía sin control = caos.

El control de la asincronía sólo puede realizarse en OnTrade().

Es necesario identificar una solicitud concreta en OnTrade().

Así llegamos a que OrderSendAsync() debe devolver el número del ticket recibido del servidor (excluyendo la situación de time-out). El número de ticket es necesario para identificar de forma única la solicitud tanto del servidor como del cliente.

Al unificar este mecanismo, la función OrderSend( ) también puede ser rediseñada - debería devolver el número de ticket, o "-1" en el caso de que falle el envío del pedido al servidor.

Luego, en el programa, implemente una clase con la lista de tickets generados.

En cada evento OnTrade(), entendemos:

1. Si se trata de nuestra acción o, por ejemplo, de la acción de otra instancia del Asesor Experto (ya no serán necesarios los magos).

2. A qué tipo de solicitud estamos respondiendo.

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

Por lo tanto, OrderSendAsync() debería devolver el número de ticket recibido del servidor (excluyendo la situación de timeout). El número de ticket es necesario para identificar inequívocamente la solicitud tanto con el servidor como con el cliente.

Hola. ¿Sabes lo que es async?
 
TheXpert:
Hola. ¿Sabes siquiera lo que es la asincronía?
<<"¡Olvídate de la asincronía sincrónica!
 
Ahora estamos discutiendo añadir una función OnTradeResult(MqlTradeResult&info), que tendrá detalles exactos sobre las respuestas del servidor.
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса
  • www.mql5.com
Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса - Документация по MQL5
 
Renat:
Ahora estamos discutiendo la adición de la función OnTradeResult(MqlTradeResult&info) que tendrá detalles exactos de las respuestas del servidor.

En mi opinión, debería verse así desde el lado del usuario:

el usuario escribe una clase para trabajar con punteros y le adjunta la clase de procesamiento de señales comerciales.

Cuando aparece una señal, se crean nuevos objetos y se envía una petición al servidor, respectivamente, el objeto existe hasta que se ejecuta la señal.

OnTrade supervisa el destino y toma una decisión (una u otra) o envía una nueva solicitud o destruye el objeto a medida que ha ido avanzando.

Este esquema necesita la identificación de qué objeto procesar en relación con la activación de este evento comercial.

 
Urain:

En este esquema, es necesario identificar qué objeto procesar en relación con la activación de este evento comercial.

¿Cuál es el problema?
 
TheXpert:
¿Cuál es el problema?

¿Estás bromeando?

El comercio es ahora sin rostro, no se puede saber qué objeto de la lista debe ser procesado a medida que llega.

 
Urain:

¿Me estás tomando el pelo?

En absoluto. Por cierto, no vale mucho la pena molestarse con OnTrade, porque no vendrá el 100% de las veces (es más o menos lo mismo que el error 1 en MT4)

Es decir, todavía tienes que contratar un seguro.

¿No es mejor "hacerlo bien"?

 
TheXpert:

En absoluto. Por cierto, no vale mucho la pena molestarse con OnTrade, porque no vendrá el 100% de las veces (que es casi lo mismo que el error 1 en MT4)

Es decir, todavía tienes que contratar un seguro.

¿No es mejor "hacerlo bien"?

¿Justificar por qué el comercio no entra en el ~100% de las veces?
 
Urain:
¿Justificar por qué el comercio no entra en el ~100% de las veces?
Porque los paquetes rotos, las conexiones caídas, etc. son una mierda. Poco fiable. Poco fiable... tienes que recuperarte.
Razón de la queja: