Aceptación de órdenes SL/TP - página 7
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
ZZY Ya he descrito anteriormente las órdenes perdedoras en posts anteriores, y ahora me gustaría añadir la siguiente. El precio alcanzó el punto de toma de una posición abierta. El servidor ha generado la correspondiente orden de mercado TP y la ha entregado al terminal (los Asesores Expertos la han visto). Entonces esta orden de TP-market desapareció no sólo del Terminal, sino también del Servidor.
Desde el punto de vista arquitectónico, es así.
La comprobación puede fallar si, por ejemplo, hubo un disparo de TP de una posición abierta, que ya está en estado de cierre.
Así, podemos ver las órdenes completas actuales en el terminal (pasarán la comprobación y estarán en el historial de operaciones (incluso en el caso de los rechazos)) y las órdenes fantasma (no pasarán la comprobación y estarán ausentes en el historial de operaciones). Ambos tendrán sus propias entradas. En teoría, los pedidos fantasma podrían tener los mismos billetes.
Este esquema está diseñado debido a la arquitectura asíncrona del servidor MT5. Se parece un poco a la lógica de OrderSendAsync del Terminal. Es difícil decir si el servidor envía correctamente la información sobre los pedidos fantasma al terminal antes de comprobar que son correctos.
Característica TP.
Función TP.
Técnicamente, no hay ninguna contradicción: El TP en el ejemplo se establece antes que la orden limitada - por eso se ejecuta antes. El TP se ejecuta de una manera extraña en Ж-eso es otro tema
Si primero abrimos una posición, luego se establece el TP y sólo entonces se ejecuta el TP, el resultado sería el mismo - entonces tenemos mucho que pensar.
Técnicamente no hay ninguna contradicción: El TP en el ejemplo se establece antes que la orden limitada - por eso se ejecuta antes. Pero el TP se ejecuta de una manera extraña - eso es otra cuestión.
Si primero abriéramos una posición, luego colocáramos una orden de Límite y sólo entonces TP, el resultado sería el mismo - entonces tendríamos mucho que pensar.
Este ejemplo es ilustrativo. Las conclusiones no provienen del ejemplo.
El ejemplo es ilustrativo. Las conclusiones no son del ejemplo.
Por lo tanto, haga un ejemplo en el que el error sea evidente: es obvio que, en igualdad de condiciones, no es normal que el TP se ejecute antes que la orden limitada que lo precede
Por lo tanto, haga un ejemplo en el que el error sea evidente: es obvio que, en igualdad de condiciones, no es normal que TP se ejecute antes que la orden de Límite que la precede
No necesito pruebas. MQ sabe cómo funciona.
No necesito pruebas. MQ es consciente de cómo les funciona.
Dudo que conozcan los detalles. Recuerdo que me argumentaron durante varias páginas que no había ningún error (entonces todavía era una práctica), luego (después de varias páginas más) admitieron que algo estaba mal - decidieron investigarlo
Y si no hay un ejemplo específico e inequívoco, entonces (en las realidades actuales) consecuentemente no hay razón para investigarlo
Y si no hay un ejemplo concreto e inequívoco, entonces (en las realidades actuales) consecuentemente no hay razón para investigarlo.
Un ejemplo no siempre da una razón para tratarla. Los MQ simplemente no ven el problema, o lo consideran irrelevante.
Un ejemplo no siempre da lugar a un problema. Los MQ simplemente no ven el problema, o lo consideran irrelevante.
Un problema importante es sólo si: El TP no se ejecuta (el precio se ha ido - no hay tiempo) y como consecuencia el límite tampoco se ejecutará
Por cierto, sí, es interesante. Si un limitador pequeño está en el mismo nivel que el TP de una posición enorme, y ese TP es redirigido porque es grande, el limitador ni siquiera tendrá la oportunidad de llenarse?
Esto se puede manipular, supongo.