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
fxsaber:
La función que indica la necesidad de una envoltura está marcada en rojo. Su problema se describe aquí. Algunos recordarán que se trata de un antiguo problema de reapertura de posiciones, que en la antigüedad se solucionaba con el Sleep, esperando a que la posición se abriera después del OrderSend. Pero en realidad, este problema no tiene nada que ver con OrderSend. Debe ser capaz de leer correctamente el entorno comercial.
La derecha es un ejemplo sencillo.
La lista de pedidos, al igual que la lista de posiciones, no se actualiza instantáneamente. Creo que no podemos prescindir de Sleep-crutch.
Probablemente sea más correcto OnTradeTransaction
La lista de órdenes, al igual que la lista de posiciones, no se actualiza instantáneamente. imho, no podemos prescindir de Sleep-crutch.
Probablemente, sería mejor utilizar OnTradeTransaction.
Si hay un problema esperando la actualización del entorno, ¿cómo puede ayudar Sleep? Ayudará o no.
Por lo tanto, el enfoque debe ser desde el otro lado: después de enviar una orden para abrir una posición o establecer una orden pendiente, debemos esperar el resultado y no enviar más órdenes para abrir o establecer. Por lo tanto, necesitamos una bandera que nosotros mismos manejamos en lugar de confiar en Sleep que sólo da el retraso de la ejecución del programa, pero no comprueba el resultado de una solicitud de comercio enviado por el propio programa que debe saber qué hacer después de que - para establecer una bandera y trabajar de acuerdo a la lógica de los resultados de espera. Después de esperar el resultado, se elimina la bandera.
Pregunta: ¿Qué ocurrirá si después de enviar una orden de mercado hasta el siguiente tick la orden de mercado no es colocada por el servidor?
Será exactamente lo mismo que en MT4 - si no hay nada, no se contará.
Puede haber varias razones para una orden de comercio de este tipo
- OrderSend o OrderSendAsync de terceros - no del programa en el que leemos el entorno comercial. Incluso puede que no sea desde el terminal en el que se ejecuta el programa. En este caso, no se puede hacer nada. Todo es igual que en MT4 en estas situaciones.
- OrderSend o OrderSendAsync - se inician desde el programa en el que se lee el entorno comercial. En el caso de OrderSend, todo está claro, ya que OrderSend terminará su ejecución con un resultado claro. En el caso de OrderSendAsync podemos hacer dos cosas - pasar los datos a los siguientes eventos según el primer paradigma, o hacer OrdersAsyncWait() (no tengo el código), como se hace en una simulación de transferencia de datos asíncrona regular en MT4 (implementación de múltiples hilos).
Probablemente debería decir unas palabras sobre OrderSendAsync en MT4. En cualquier etapa de la ejecución del programa es posible ver cuán ocupado está un hilo comercial correspondiente y qué está haciendo exactamente. En este sentido, la asincronía personalizada en MT4 nos da muchas más posibilidades que la de MT5. Pero en MT4 se implementa ejecutando "clientes" en cada gráfico, es decir, caro. En MT5 es posible escribir la misma funcionalidad e incluso sin muchos gráficos - ejecutando el script en un objeto OBJ_CHART, pero todavía habrá un ligero retraso. Es decir, OrderSendAsyncCustom será ligeramente más lento que OrderSendAsync, pero seguirá siendo mucho más rápido que OrderSend + todas las ventajas de la implementación personalizada.La lista de órdenes, al igual que la lista de posiciones, no se actualiza instantáneamente. imho, no podemos prescindir de Sleep-crutch.
Probablemente, sería más correcto utilizar OnTradeTransaction
MqlTradeTransaction puede ser necesario sólo cuando se elige el paradigma apropiado al trabajar con OrderSendAsync. En otros casos, OnTradeTransaction == OnTrade en sentido y no juega más papel que OnTick o OnTimer.
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Errores típicos y cómo solucionarlos al trabajar con un entorno comercial
fxsaber, 2018.02.19 22:36
Existen dos paradigmas de trabajo con el entorno de trading, escribiendo EAs.
El resaltado denota que el mismo código comercial se ejecuta en cada función On. El correspondiente código de no comercio completa todo lo demás.
Será exactamente lo mismo que en MT4 - si no hay nada, no se contará.
Es decir, en el siguiente tick el programa envía una nueva solicitud de apertura. Como resultado, tenemos el mismo problema: múltiples aperturas.
El Asesor Experto debe tener la siguiente lógica:
Es decir, en el siguiente tick, el software envía una nueva solicitud de apertura. Como resultado, tenemos el mismo problema: múltiples aperturas.
Sería bueno leer todo el post.
El EA debe tener la siguiente lógica:
La bandera de espera sólo está disponible para el segundo caso y OrderSendAsync. En el caso de OrderSend, el indicador de espera no es necesario en absoluto. OrderSendAsync sin bandera de espera es OrdersAsyncWait().
Se puede comprobar cualquier teoría en la práctica.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Errores típicos y cómo solucionarlos al trabajar con un entorno comercial
fxsaber, 2018.02.20 00:01
ZZY Introduzca este código aquí y compruebe el resultado en el servidor de demostración.
Es una buena idea leer el post en su totalidad.
La bandera de espera sólo es posible para el segundo caso y OrderSendAsync. Para OrderSend la bandera de espera no es necesaria en absoluto. OrderSendAsync sin bandera de espera es OrdersAsyncWait().
Cualquier teoría puede probarse en la práctica
Me guío por los resultados prácticos.Bueno, escribí para el modo asíncrono. Con la sincronización no es necesario esperar: el resultado ya está en la respuesta de la consulta.
Bueno, yo escribí para el modo asíncrono.
Se ha dadouna respuesta detallada desde el principio.
Se diouna respuesta amplia desde el principio.
Debo haber leído mal :)
No he visto ningún paso para evitar el error de descubrimiento múltiple. Sólo los "paradigmas" generales ;)
Por eso he señalado la lógica aproximada, que es redundante - la bandera se comprueba en una función (wrapper) que abre posiciones / establece órdenes pendientes. O quizás también en la función de seguimiento de la señal.
Hay que pensar en la mejor manera.
la bandera se comprueba en la función (wrapper) de apertura de posiciones/colocación de órdenes pendientes. O quizás también en la función de seguimiento de la señal.
Prefiero mucho más la solución vía OrdersAsyncWait(), cuando la salida de la función On se hace siempre sin colgar el estado. Entonces, la siguiente lectura del entorno comercial con una pizarra limpia es lo más relevante posible.
El uso de OrderSendAsync debería ser siempre apropiado. La única situación en la que puede ocurrir es el envío de varias (> 1) órdenes comerciales, independientes entre sí, sobre la misma señal. Por lo tanto, lo de OrderSendAsync nunca tiene sentido en los demás casos.
SZZY Hay un tema aparte en el que OrderSendAsync es muy relevante - multiasesores: varios TS independientes en un Asesor Experto. El OrderSend rara vez es adecuado allí e incluso el OrderAsyncWait( const string Symb) no es bueno ya que en principio no se permite el Sleep.