
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
Úsalo.
Este es un buen ejemplo. Pero hay una pregunta que me inquieta. ¿Qué pasa si OnTradeTransaction() no devuelve los datos al procesar la orden? Bueno, puede que se pierdan de alguna manera. El servidor lo ha enviado pero el terminal no lo ha recibido. ¿Cuánto se garantiza que obtendré el número requerido de llamadas a la función OnTradeTransaction() para el 100% de las órdenes enviadas y que todos los informes de transacciones llegarán a la terminal (me interesa transaction.type = TRADE_TRANSACTION_REQUEST principalmente).
Porque si no obtengo esta respuesta (por corte de conexión, por ejemplo) no borro la bandera y todo se queda parado.
No lo he comprobado, pero quizás después de OrderSend TODOS los EAs reciben el evento correspondiente para OnTradeTransaction.
Entonces todo se resuelve sin muletas y para múltiples EAs sobre el mismo símbolo.
Este es un buen ejemplo. Pero hay una pregunta que me inquieta. ¿Qué pasa si OnTradeTransaction() no devuelve los datos de procesamiento de la orden? Bueno, puede que se pierdan de alguna manera. El servidor lo ha enviado pero el terminal no lo ha recibido. ¿Cuánto se garantiza que obtendré el número requerido de llamadas a la función OnTradeTransaction() para el 100% de las órdenes enviadas y que todos los informes de transacciones llegarán a la terminal (me interesa transaction.type = TRADE_TRANSACTION_REQUEST principalmente).
Porque si no recibo esta respuesta (por corte de conexión, por ejemplo) no quitaré la bandera y todo se mantendrá.
Me ha pasado varias veces que el evento OnTradeTransaction no se ha producido,
Por lo tanto, escribí una función que comprueba el estado de las órdenes utilizando un temporizador con un período de 0,5 segundos.
La implementación complica el código general del Asesor Experto, pero no hay una garantía del 100% cuando se trabaja a través de Internet,
que todo funcione como un reloj.
Añadido por
Tengo la idea de comprobar aquí
https://www.mql5.com/ru/blogs/post/557544
Me ha pasado varias veces que el evento OnTradeTransaction no se ha producido,
Por lo tanto, escribí una función que comprueba el estado de las órdenes utilizando un temporizador con un período de 0,5 segundos.
La implementación complica el código general del Asesor Experto, pero no hay una garantía del 100% cuando se trabaja a través de Internet,
que todo funcione como un reloj.
Añadido por
Tengo la idea de comprobar aquí
https://www.mql5.com/ru/blogs/post/557544
Me parece que el tipo está tratando de atravesar una puerta abierta creando códigos mágicos especiales para cada transacción. Existe un order_id con el que se puede identificar un pedido de forma única.
¿O es que no entiendo nada?
Me parece que el tipo está abriendo una puerta creando códigos mágicos especiales para cada comercio. Hay un order_id que se puede utilizar para identificar de forma única el pedido.
¿O es que no entiendo nada?
Sí, hay un order_id, pero lamentablemente a veces los eventos no llegan a OnTradeTransaction
(Lo he tenido varias veces personalmente).
¿Y dónde "poner" el order_id?
Añadido por
Aquí, hoy ha habido un retraso en la respuesta del servidor
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
Sí, hay un order_id, pero lamentablemente a veces los eventos no llegan en OnTradeTransaction
(Yo lo he tenido varias veces personalmente).
¿Dónde "meter" el order_id entonces?
Añadido por
Aquí, hoy ha habido un retraso en la respuesta del servidor
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
El otro día tuve un "bafle" diferente.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59699 mksec.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59712 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Retcode = 10009. Slippage = 1379.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Position is closed in 127691 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = 0
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction Unexpected transaction request.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Retcode = 10009. Slippage = -40993.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Position is closed in 1339448077 mksec.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = -1
Envié tres pedidos y hay un registro claro de ello en mi registro. Después, la función OnTradeTransactions() TRADE_TRANSACTION_TYPE ha sido llamada cuatro veces.
El código de la función comienza con comprobaciones:
const MqlTradeRequest& request,
const MqlTradeResult& results)
{
if(transaction.type == TRADE_TRANSACTION_REQUEST && request.action == TRADE_ACTION_DEAL)
{
if(request.magic == ExpertMagic)
{
Es decir, sólo TRADE_TRANSACTION_REQUIEST con su propio sello de experto puede entrar, donde las impresoras están...
El servicio de asistencia comenzó a persuadirme de que tengo dos EAs idénticos en pie (obviamente en el mismo gráfico, a juzgar por el registro). Y entonces dijeron: "eres un tonto, arregla los errores del código".
En definitiva, según ellos no puede ser. Pero el registro muestra claramente que el evento llegó cuatro veces.
Sí, hay un order_id, pero lamentablemente a veces los eventos no llegan en OnTradeTransaction
(Yo lo he tenido varias veces personalmente).
¿Dónde "meter" el order_id entonces?
Añadido por
Aquí, hoy he tenido un retraso en la respuesta del servidor.
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
Pero de todos modos, sigo sin entender por qué no podemos buscar el orden por el ticker? Es muy fácil comprobar cuáles de las órdenes que hemos enviado no han llegado a TradeTransaction. Y luego sólo hay que mirar el estado de la orden con este billete en el historial.
Sin embargo, el historial de pedidos sólo muestra los pedidos con el estado LLENADO.
¿Y todavía no está claro por qué no se puede buscar la orden por el ticker? Después de todo, es fácil comprobar qué orden no ha llegado a TradeTransaction. Y luego sólo mira el estado de la orden con este ticker en el historial.
Aunque, cuando lo probé personalmente, en el historial de pedidos, sólo había pedidos con el estado LLENADO.
Sí, porque la orden puede no estar en el historial(orden pendiente, etc.)
Añadido
Y tienes el código equivocado
Sí, porque la orden puede no estar en el historial(orden pendiente, etc.)
Añadido por
Y tienes el código equivocado
¿Qué pasa ahí? ¿Cuántos errores puedes cometer en dos líneas de código?
¿Qué pasa ahí? Cuántos errores se pueden cometer en dos líneas de código.
No dos, uno :)
TRADE_TRANSACTION_REQUEST es necesario cuando se utiliza OrderSendAsymc para obtener el ticket de pedido.