Procesamiento de OnTradeTransaction - página 2
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
¿Podemos tener >=2 órdenes de compra y de stop al mismo tiempo?
Sí, así es, hicimos una entrada inicial y establecimos un TP y una orden de stop. Luego, un tiempo después, podemos añadir más entradas y establecer más TPs y stops.
En caso de pérdida, recuerdo los pedidos realizados, el ticket de la última transacción contabilizada, la hora del último registro (cambio) del estado, y periódicamente, así como durante el initing, sincronizo la lista de pedidos y compruebo si hay transacciones no contabilizadas.
La ocurrencia de eventos al azar es la norma, la ausencia de órdenes (temporales) tanto en las órdenes como en el historial no es infrecuente y puede ocurrir tanto antes como después de que se haya producido un acuerdo.
Una posición en la compensación recibe un ticket de la primera orden y en las operaciones posteriores (cambios) lo guarda hasta que se cierra (es decir, se convierte en 0,0).
Dependiendo del volumen de la orden, puede generar varias operaciones.Comparta sus experiencias e ideas, por favor.
No lo estás haciendo bien desde el principio.
¿Por qué los magos y todo tipo de cheques?
El ticket de una orden es un identificador único.
Si envía una orden sincrónica, recibirá un ticket como resultado de la función.
Si envía una orden asíncrona, obtendremos el ticket en OnTradeTransaction.
Añadido
Y aquíhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220
es una buena función para comprobar el orden
Sí, así es, hicimos una entrada inicial y establecimos un TP y una orden de stop. Luego, al cabo de un tiempo, podríamos hacer una recarga y colocar otro TP y órdenes de stop.
Las órdenes limitadas que requieren TP/SL podrían ejecutarse parcialmente. Al mismo tiempo, los TP en forma de órdenes de límite se ejecutarán de la misma manera. Por ejemplo, el TP se ejecuta en un tercio del volumen - el SL debe ser disminuido en la misma cantidad.
En definitiva, una lógica bastante desagradable para coger todos los trucos.
La tarea debe ser implementada en OnTrade. No debería ser difícil de aplicar.
Lo estás haciendo mal desde el principio.
¿Por qué los magos y todo tipo de cheques?
El ticket de una orden es un identificador único.
Si está enviando una orden sincrónica, entonces el ticket se recibe como resultado de la función.
Si envía una orden asíncrona, obtendremos el ticket en OnTradeTransaction.
Añadido
Y aquíhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220
es una buena función para comprobar el orden
En caso de pérdida de un evento, recuerdo los pedidos realizados, el ticket de la última transacción contabilizada, la hora de la última entrada (cambio) de estado, y periódicamente, así como cuando ocurre, sincronizo la lista de pedidos y compruebo si hay tratos no registrados.
La ocurrencia de eventos al azar es la norma, la ausencia de orden (temporal) tanto en las órdenes como en la historia no es infrecuente y puede ocurrir tanto antes como después de que se haya producido un acuerdo.
La posición en la compensación obtiene un ticket de la primera orden y en las operaciones posteriores (cambios) lo guarda hasta que se cierra (es decir, se convierte en 0,0).
Bueno, dependiendo del volumen de la orden, puede generar múltiples operaciones.Uno de los objetivos del robot era deshacerse de la dependencia local. Es decir, sólo recibe datos del mercado sin estar ligado a las variables del terminal o de un PC. Esto significa que en caso de una necesidad urgente tengo que cambiar a otro PC y el robot lo recogerá todo.
Ahora he visto otro fallo interesante. He recibido 2 transacciones TRADE_TRANSACTION_DEAL_ADD idénticas. Lo siento, ¿qué demonios es esto?) El robot terminó poniendo 2 topes en una transacción.
2019.02.08 10:55:29 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Símbolo: RTS-3.19
Billete de oferta: 12674810
Tipo de oferta: DEAL_TYPE_BUY
Billete de pedido: 82646001
Tipo de pedido: ORDER_TYPE_BUY
Estado del pedido: ORDER_STATE_STARTED
Tipo de hora del pedido: ORDER_TIME_GTC
Fecha de vencimiento del pedido: 1970.01.01 00:00
Precio: 119700
Precio de activación: 0
Stop Loss: 0
Toma de beneficios: 0
Volumen: 1
Posición: 82646001
Posición por: 0
2019.02.08 10:55:32 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Símbolo: RTS-3.19
Billete de oferta: 12674810
Tipo de oferta: DEAL_TYPE_BUY
Billete de pedido: 82646001
Tipo de pedido: ORDER_TYPE_BUY
Estado del pedido: ORDER_STATE_STARTED
Tipo de hora del pedido: ORDER_TIME_GTC
Fecha de vencimiento del pedido: 1970.01.01 00:00
Precio: 119700
Precio de activación: 0
Stop Loss: 0
Toma de beneficios: 0
Volumen: 1
Posición: 82646001
Posición por: 0
Los eventos de transacción(TRADE_TRANSACTION_DEAL_ADD) se producen varias veces regularmente.
Afortunadamente, sólo se repite el más reciente (al menos yo no pillé los más antiguos).
Para filtrar basta con comprobar si el ticket de la transacción es el mismo que el anterior.
Los eventos de transacción(TRADE_TRANSACTION_DEAL_ADD) se producen varias veces regularmente.
Afortunadamente, sólo se repite el más reciente (al menos yo no pillé los más antiguos).
Para filtrarlo, basta con comprobar si el ticket de la transacción es el mismo que el anterior.
No varias veces, sino por el número de EAs que están trabajando en el terminal.
Por lo tanto, cada EA debe procesar su propia orden
No varias veces, sino por el número de EAs que están trabajando en el terminal.
Por lo tanto, cada EA tiene que procesar su propia orden
Su código protege contra el hecho de que era un comercio de este EA.
Yo y TS estamos hablando de casos en los que OnTradeTransaction con el tipoTRADE_TRANSACTION_DEAL_ADD se llama varias veces para una operación, es decir, los otros campos de MqlTradeTransaction contienen exactamente los mismos datos.
Significa que en su caso el código de procesamiento puede ser ejecutado varias veces.
Quizá no sea el caso de todos los corredores. Pero sucede regularmente en todos los corredores de bolsa con los que he trabajado.
Su código protege contra el hecho de que era el comercio de este EA.
Yo y TS estamos hablando de casos en los que OnTradeTransaction con el tipoTRADE_TRANSACTION_DEAL_ADD se llama varias veces para una operación, es decir, otros campos de MqlTradeTransaction tienen exactamente los mismos datos.
Significa que en su caso el código de procesamiento puede ser ejecutado varias veces.
Quizá no sea el caso de todos los corredores. Pero sucede regularmente con todos los corredores con los que he trabajado.
Opero en Otkryvashka en real y lo pruebo en demo pero no tengo múltiples disparadores.
Publique su código paraTRADE_TRANSACTION_DEAL_ADD
Los eventos de transacción(TRADE_TRANSACTION_DEAL_ADD) se producen varias veces regularmente.
Afortunadamente, sólo se repite la más reciente (al menos no he pillado las más antiguas).
Para filtrar, basta con comprobar si el ticket de la transacción es el mismo que el anterior.
Sí, gracias. Acabo de hacer eso después de lo que vi.
En cuanto al problema original, puse un resguardo para tener tiempo de bombear la transacción de borrar un pedido y añadirlo al historial. Observado.
La imperfección de la plataforma en este aspecto es muy triste. Cosas que deberían ir juntas se hacen por separado.
No varias veces, sino por el número de EAs que trabajan en el terminal en este momento.
Por eso cada EA tiene que procesar su propia orden