OnTradeTransaction - página 7

 
fxsaber:

De acuerdo. Pero desgraciadamente en MT5, a diferencia de MT4, el entorno de trading puede no coincidir con la realidad. Por ejemplo, cuando una orden pendiente se ejecuta durante unos milisegundos, puede no estar en ningún sitio. Y aquí incluso OnTradeTransaction no ayudará.

Quizás, OnTrade, según tengo entendido se genera en el propio terminal ya en base a las transacciones.

¿O quiere decir que cuando una orden pendiente se dispara en el manejador OnTrade, no se puede detectar una nueva posición abierta?

 
Aleksey Mavrin:

Quizás OnTrade, según tengo entendido se genera en el propio terminal en base a las transacciones.

¿O estás diciendo que una nueva posición abierta puede no ser detectada en el manejador OnTrade cuando se dispara una orden pendiente?

En cualquier función On. En este sentido, hay un agujero en MT5. Es poco probable que lo parcheen.

 
fxsaber:

En cualquier función On. En ese sentido, hay un hueco en la MT5. Es poco probable que lo parcheen.

Si es así, es lamentable. Prácticamente pierde el sentido de OnTrade. Tendremos que comprobarlo. Lo ideal es que se llame a OnTrade aproximadamente cuantas veces se active la orden:

para las paradas:

- se crea y envía una orden de mercado

- la orden pendiente se ha movido al historial

- la orden se ha ejecutado, se ha registrado un acuerdo

- la orden de mercado se ha trasladado al historial

- posición creada

para la orden de Límite:

- orden limitada activada transacción escrita

- La orden pendiente se ha trasladado al historial

- se ha creado un puesto de trabajo

Suponiendo esto último, ya debería haber una posición y no las anteriores, es lógico que no la haya, ¿eh?

He llamado a funciones para comprobar todos los estados de negociación - operaciones, posiciones y órdenes - en OnTrade. Hasta ahora todo parece funcionar bien, pero no he tenido operaciones demasiado complejas.

 
fxsaber:

Por qué he venido al foro, hay tantos problemas sin resolver))

Gracias, lo investigaré. Hasta ahora he leído el resaltado, no es un problema sino una característica. En las bases de datos, y en general, el concepto de transacción y significa que TODO

necesario para realizar una consulta y mantener la corrección de la base de datos se hace, y después de la transacción puede trabajar con la base de datos, no habrá errores.

Si alguna acción (y para escribir una fila en cualquier tabla a veces es necesario hacer más de una y asegurarse de que las anteriores se hicieron con éxito)

Los cambios se revierten y la transacción se rechaza. A lo que voy con esto, probablemente, no deberías esperar de MT el nivel de DBMS :)

Aquí todas las operaciones intermedias tienen que ser vigiladas y comprobadas, de nuevo en algún lugar da más flexibilidad.

Pero todo me parece bien - primero, el servidor dice que la orden está hecha y el terminal la borra en el archivo, luego (más tarde) el servidor dice que abrió una posición y puede que no se abra debido a algún error, entonces debería ser cero-cero.

Lo comprobaré e informaré de los resultados en detalle.

 
Aleksey Mavrin:

Pero todo tiene sentido para mí - el servidor primero informa que la orden se ejecuta, el terminal la borra en el archivo, entonces (más tarde) el servidor informa que abrió una posición

La orden no está en el historial y no está entre las actuales. Y no hay posición. Es decir, no hay nada.

 
Aleksey Mavrin:

Pero todo tiene sentido para mí - el servidor primero informa que la orden se ejecuta, el terminal la borra en el archivo, entonces (más tarde) el servidor informa que abrió una posición, pero puede que no se abra debido a algún error, entonces debería ser cero-cero.

No puedo decir en este foro o en cualquier otro lugar que he leído los mensajes del administrador Renat (probablemente foro rápido), pero parece que escribió que la única comprobación de la orden pasa por el servidor es proporcionar los requisitos de margen, a continuación, la orden "vuela" a través del conector a la bolsa, entonces la incertidumbre de la ejecución de la orden, en principio, es posible, el servidor no sabe a qué precio se ejecuta la orden

 
Además del ejemplo dado por fxsaber, en la práctica también se da el caso de que haya un ticket tanto entre las órdenes como entre las posiciones abiertas. la situación también dura varios milisegundos (aunque no se comprueba en las últimas builds). el mecanismo de comprobación debe ser diferente, así que prepárate de antemano :)
 
Igor Zakharov:
Aparte del ejemplo dado por fxsaber, en la práctica se da el caso de que haya un ticket tanto entre las órdenes como entre las posiciones abiertas. esta situación también dura varios milisegundos (aunque no se comprueba en las últimas builds). el mecanismo de comprobación debe ser diferente, así que prepárate de antemano :)

Esta situación se maneja de tal manera que para los EAs de MT4 todo sigue igual en MT5 que en MT4. Pero con los pedidos fantasma, hay que anotarlos.

 

En los robots "normales", el caso que he descrito, no lo noté en absoluto; pero en un caso me pidieron que hiciera un sistema de seguridad: la condición era que las posiciones estuvieran siempre bloqueadas (ya sea con posiciones reales o con una orden pendiente), es decir, que el número de lotes de compra fuera igual al número de lotes de venta. Este es el caso que me introdujo en los matices del recuento de orden/posición/comercio en un cinco.

La diferencia, según me expliqué :) es que el cuatro, al obtener una respuesta del broker, primero sincroniza sus "tablas" con las órdenes abiertas y el historial, y luego informa al usuario de la respuesta del broker. El cinco nos transmite inmediatamente esta respuesta, y al mismo tiempo corrige sus "tablas" (y todos los programas mql leen los datos de estas "tablas"). Este es el momento en el que cogemos el temporizador de milisegundos. Pero entonces, ¿por qué no lo detectamos en el probador?

En general, lo he soportado...