![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
¡Oh, Dios mío! ¿Es válido en la historia?
¿Papaklass probablemente quería decir que OnTradeTransaction devuelve errores?
Si la información en OnTradeTransaction puede no ser válida, tenemos que tomarla del historial para asegurarnos de que es válida.
Si la información de onTradeTransaction no es siempre fiable, tenemos que tomarla del historial para asegurarnos de que la información fue procesada.
La pregunta es ¿por qué demonios necesitamos OnTradeTransaction si tenemos que tomar la información del historial de todos modos? - Sólo lo necesita para la comprobación de errores. El corredor rechazó la orden y recibimos la respuesta de por qué fue rechazada en OnTradeTransaction y la analizamos.
¿pero por qué babear por 9 páginas?
Por favor, no seas grosero. Por cierto, ¡ya son 10!
Y estás en tu derecho de no leer nada de lo que se escribe aquí.
C-4, se procesará, por supuesto, pero ¿por qué la necesidad de OnRefresh()?
Muchos eventos -> un manejador.
¡Errores de todos los rincones en una pila! :)
No son los errores los que se envían, sino los datos. Los errores pueden estar en el manejador, pero son fáciles de arreglar porque sólo hay un manejador.
Eso es exactamente lo que quiero decir. Necesitas separación de eventos.
No son los errores los que se envían, sino los datos. Los errores pueden estar en el manejador, pero son fáciles de arreglar porque sólo hay un manejador.
No hay que separar los eventos, hay que separar los manejadores. Los eventos generan datos. Cada tipo de datos es manejado por un manejador diferente. No importa quién haya recibido los datos, lo importante es que haya un único manejador para cada tipo de datos.¿Qué no se comparte aquí?
Y luego están
¿Qué no se comparte aquí?
Lo que sugieres (tratamiento de los tipos de datos) es lo que tiene MK en este momento. El manejador OnTradeTransaction maneja un determinado tipo de datos MqlTradeTransaction. Es cierto, en este tipo de datos ponen muchas cosas, es decir, tipos de datos correspondientes a diferentes eventos.
Sugiero que cada evento tenga sus propios datos y su propio manejador. A tantos eventos, tantos manejadores. La división de eventos (abrir una posición, cerrar una posición, colocar una orden, modificar una orden, modificar una posición, etc.). Y son los desarrolladores los que deciden qué tipos de datos asignar a cada evento.
Con la palabra "manejador", no me refiero a una función del sistema que recibe algún evento, sino a algún módulo del Asesor Experto que analiza este evento. Para multiplicar el número de funciones en... Cada uno de ellos para su propio evento - no tiene sentido, más aún es elemental crear un número necesario de manejadores personalizados. Así es como se hace en mi caso:
Puede parecer extraño que una misma clase de evento se pase a manejadores completamente diferentes que requieren tipos de datos completamente diferentes. Por ejemplo, OnMouseMove requiere una máscara de teclas pulsadas en el ratón y sus coordenadas, OnKeyDown() requiere el código de una tecla pulsada, OnOrderChange requiere un ticket de la orden que se cambió y probablemente un enum que describa el cambio exacto. Se podría pensar que la clase de evento contiene campos para todos los eventos posibles. Pero no es el caso. De hecho, el objeto de la clase de evento ni siquiera puede existir, ya que su constructor está oculto en el área protegida. Pero sus descendientes existen en abundancia - cada uno de ellos para manejar sólo un evento diferente. Sin embargo, para cualquier evento existe un identificador que indica a qué tipo pertenece. Sabiendo este identificador, puede pasar con seguridad de un tipo más grande a uno más pequeño. Es el tipo de hijo al que se realiza la conversión implícita cuando se pasa el manejador. Veamos cómo nuestros manejadores ven realmente el evento:
Hermoso... Parece que sólo hay un evento, pero en realidad podría haber docenas de ellos. El evento parece no contener prácticamente ninguna información, excepto su tipo, pero de hecho, los manejadores se refieren libremente a métodos conocidos sólo por ellos.No hay eventos "externos" e "internos", sólo eventos. Y el número de estos eventos es potencialmente infinito. Un evento puede ser cualquier cosa. Un evento puede contener todo tipo de datos. Siguiendo esta filosofía alcanzamos un nuevo y más alto nivel de abstracción de datos. ¡Por qué crear restricciones en tu cabeza, por qué imponer una clasificación que limite la abstracción!
La diferencia esencial entre los eventos internos y externos es el tiempo de ejecución. Los eventos internos tienen un tiempo de ejecución prácticamente nulo, mientras que los externos tienen cientos de milisegundos o segundos.
Los eventos no tienen un tiempo de ejecución. Si un evento ha llegado, ya se ha ejecutado. Así es como funciona el modo asíncrono. Por tanto, es un error clasificar los eventos en internos y externos por la rapidez con la que se ejecutan. Lo correcto es no clasificar en absoluto, sino pensar de forma muy abstracta a partir de la aplicación concreta.