Secuencia de ejecución de Init() y DeInit() - página 12
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
Eso es, las lamentaciones han comenzado...
Lo que pides es exactamente lo que no tienen las aplicaciones de escritorio normales.
¿Qué no hay en la aplicación? ¿Sincronización? )))
Si los desarrolladores no hicieran todas estas características que ya están "fuera de la caja", los escritores de programas MQL se enfrentarían constantemente a todos los encantos del desarrollo de escritorio, ya sea la seguridad o la velocidad de ejecución.
1. ¿Qué es lo que no está en las aplicaciones? ¿Sincronización? )))
2) Estás haciendo un razonamiento no científico sin hechos. En MT4, los indicadores operan con sucesivos OnInit() y DeInit(). Hay una desventaja: todos los indicadores funcionan en un solo hilo. Se puede solucionar escribiendo correctamente el indicador, lo que también es necesario en MT5. Aunque, MT5 no ha dejado de hacerlo - de todos modos, los indicadores de un gráfico siguen funcionando en un hilo.1. ¡de qué sincronización estás hablando!
2. En MT4, como parte de la ejecución del código del indicador, primero se ejecuta el init y luego el deinit, ¡¡¡qué más necesitas!!! Es lo mismo en MT5.
Varias personas ya me pidieron que diera un ejemplo específico de una tarea, que es problemática de realizar dentro del paradigma de ejecución de indicadores en MT5. ¿Habrá un ejemplo o no, un ejemplo claro, no sacado de la nada?
1. ¿De qué sincronización hablas?
Acerca de la inter-relación. Hasta que uno de los hilos no termine (el que ha recibido la orden de terminar), el otro hilo no se inicia. O, si todo ocurre en un hilo, es aún más simple: terminar todos los programas asociados con el "viejo" TF y sólo entonces iniciar los programas en el "nuevo" TF.
2. En MT4, como parte de la ejecución del código del indicador, primero se ejecuta el init y luego el deinit, ¡qué más se necesita! Lo mismo ocurre en MT5.
Sí. Este es exactamente el caso en MT4. Pero no es así en MT5. Y de esto trata el tema.
Varias personas ya me pidieron que diera un ejemplo específico de una tarea que es problemática de realizar dentro del paradigma de ejecución de indicadores en MT5. ¿Habrá un ejemplo o no, un ejemplo claro, no sacado de la nada?
Así es, no deberían. Así que ejecuta Total Commander, por ejemplo. ¿Por qué exigir a Microsoft que Windows se encargue de la secuencia "correcta" de carga/descarga de copias de TC en la RAM? ¿Es una preocupación del sistema operativo?
Al SO le importa que el TC no interfiera con otros TC y lo que hagan allí en la RAM, intercambiar archivos o lo que sea es asunto suyo.
"¡Creo que sí!" (c) Mimino, 1977.
¿Qué tiene que ver el Comandante Total con esto? Es una utilidad de bajo nivel en el sentido de que opera directamente con los recursos del sistema. En el caso de MQL, la tarea de la plataforma MT es liberar al programador de la aplicación de los cuidados del sistema, como la sincronización, que la plataforma puede proporcionar de forma más eficaz y de un solo golpe para todos. Los programadores de MQL deben pensar en el análisis de las cotizaciones y las estrategias de negociación. Este es el propósito de la MT.
¿Qué tiene esto que ver con el intercambio de archivos y datos? Considere la lógica del trabajo en el contexto de un programa MQL. Simplemente intenta utilizar los eventos OnInit/OnDeinit de acuerdo a su propósito - para comenzar correctamente desde un cierto estado y terminar correctamente con el guardado del estado. Si no sirven para este fin, entonces, como ya se ha señalado, ¿para qué sirven? A juzgar por los argumentos de los defensores -¿para que podamos bailar dentro y averiguar qué otras copias se ejecutaron antes y después, y de qué marco temporal y a cuál han cambiado? Esto tiene exactamente el efecto contrario de lo que MQ quería conseguir: que una copia no sepa nada de la otra.
Para que una copia no sepa nada y no tenga que averiguarlo, y siga funcionando sin efectos secundarios, el kernel necesita conocer todas las copias -tanto las que están apagadas como las que están arrancando- y proporcionar les un manejo elegante de los eventos init/deinit en una metáfora de cola estándar. El terminal rastrea todas las copias de todos modos, y utiliza la cola de eventos, pero por alguna razón init/deinit rompe la lógica de los eventos.
Paraque una copia no sepa nada y no tenga que averiguarlo, y siga funcionando sin efectos secundarios, el kernel tiene que ser consciente de todas las copias -tanto las que se terminan como las que se inician- y proporcionar un manejo de eventos graceful init/deinit para ellas en la metáfora de la cola estándar. El terminal mantiene un registro de todas las copias y utiliza la cola de eventos, pero por alguna razón init/deinit rompe la lógica de los eventos.
¿Cuál es el problema de almacenar el periodo en una variable principal?
¿Por qué sería necesario transferir una serie de datos entre las sucesivas ejecuciones del indicador en diferentes TFs?
Andrey, no me gustan las variables globales de los terminales. He experimentado con ellos (hace mucho tiempo) y me decepcionó mucho su velocidad y las dificultades de sincronización. Para evitar la falta de apoyo, intentaré escribir un ejemplo (un poco más adelante) que demuestre su velocidad. Tal vez algo haya cambiado y yo esté equivocado. Pero otra cosa que no me gusta de las variables globales es que tienen vida propia y son absolutamente públicas. Todo el mundo puede comprobarlos pulsando F3 y borrarlos. Cuando hay varios, es la mitad del problema, pero si todo el mundo empieza a usarlos, a mí personalmente me da la sensación de desorden en mi escritorio.
Sobre el paso de las matrices. Sí, estoy de acuerdo, no es necesario muy a menudo. Pero he aquí un ejemplo concreto: mi indicador. Su funcionamiento interno no depende de la TF seleccionada, ya que durante la inicialización descarga todas (casi todas) las TF y crea su propio array general (algo así como un array logarítmico de citas) y realiza algunos cálculos más voluminosos de arrays de índices basados en él. Al cambiar de TF, hacer una y la misma cantidad de trabajo cada vez no es en absoluto racional - habrá retrasos al cambiar de TF. También tengo en mi cabeza algoritmos para el reconocimiento de patrones, que voy a implementar, por lo que allí los cálculos de inicialización pueden tardar hasta varios segundos, y me gustaría que sólo ocurriera una vez y olvidarme de ello.
Para que una copia no sepa nada y no tenga que averiguarlo, y siga funcionando sin efectos secundarios, el kernel tiene que ser consciente de todas las copias -tanto las que se terminan como las que se inician- y proporcionar un manejo de eventos graceful init/deinit para ellas en la metáfora de la cola estándar. El terminal rastrea todas las copias de todos modos, y utiliza la cola de eventos, pero por alguna razón init/deinit rompe la lógica de los eventos.
Y ahora imagina que no hay una sola cola de eventos, sino una cola por cada personaje-periodo. Tantos periodos de carácter, tantas colas.
Ahora sugiera el orden en que se manejan las colas.
Y ahora imagina que no hay una sola cola de eventos, sino una cola por cada símbolo-período. Tantos períodos de símbolos como colas haya.
Ahora sugiera el orden en que se manejan las colas.
1. Sobre el inter-hilo. Hasta que uno de los hilos no termine (el que ha recibido la orden de terminar), el otro hilo no se inicia. O, si todo esto ocurre en un hilo, es aún más sencillo: terminamos la ejecución de todos los programas conectados con la "vieja" TF y sólo después iniciamos los programas en la "nueva" TF.
2. Sí. Es exactamente lo mismo en MT4. Pero no es así en MT5. De eso se trata el tema.
3. Anteayer di con objetos gráficos, nace una belleza: un indicador sigue existiendo y no se ha limpiado, mientras que el segundo está dibujando sobre estos objetos. Así se lo explicaremos al usuario: "Al conmutar el TF se observan perturbaciones a corto plazo". )))1) Debería hacerse como escribí antes: la base de datos acumulada debería guardarse periódicamente en un archivo u otro almacenamiento, sin problemas - abrir archivo, escribir, cerrar. Hay que hacerlo cada vez que se actualizan estos datos o periódicamente, no en ininit y deinit. (Se guarda el trabajo periódicamente cuando se escribe un programa, se escribe un artículo). Y es imposible asegurarse contra el fallo de la escritura en el archivo, a veces para asegurarse en situaciones de importancia crítica hacen lo siguiente: escriben la información actualizada en un nuevo archivo, después de la escritura con éxito borran el archivo antiguo y cambian el nombre del nuevo como estaba en el antiguo.
2) Ya lo he explicado. Cada indicador debe trabajar con sus propios objetos gráficos. Por supuesto, tenemos que comprobar la existencia de los objetos y si ya existen, tenemos que añadir 1 al nombre del objeto.
3) Bueno, ya has escrito que es solucionable.
Y estos no son problemas en absoluto. Este es el funcionamiento normal de los programas: creación de objetos únicos, guardado periódico de la información acumulada, limpieza tras la finalización.
1. Estos son sus deseos. Pero dijiste que querías el modo en que funcionan las aplicaciones de escritorio, así que el modo en que quieres que funcionen las aplicaciones de escritorio no funciona.
¿Cómo se llaman las aplicaciones de escritorio? Parece que MT5 no es una aplicación de escritorio.
2. No te inventes historias. La secuencia de oninit y ondeinit es la misma en MT4 y MT5. No existe ningún programa que empiece por deinit.
No me lo estoy inventando. Este es el tema del hilo actual. El punto es que MT5 puede ejecutar Init para el indicador que aún no ha DeInit. Sí, lo es. ¿No has leído el tema?
3) Bien, analicemos los ejemplos:
1) Hacer lo que escribí antes: la base de datos acumulada debe ser guardada periódicamente en un archivo u otro almacenamiento, sin problemas - archivo abierto, escrito, cerrado. Hay que hacerlo cada vez que se actualizan estos datos o periódicamente, no en ininit y deinit. (Se guarda el trabajo periódicamente cuando se escribe un programa, se escribe un artículo). Y es imposible asegurarse contra el fallo de la escritura en el archivo, a veces para asegurarse en situaciones de importancia crítica hacen lo siguiente: escriben la información actualizada en un nuevo archivo, después de la escritura con éxito borran el antiguo, y cambian el nombre del nuevo archivo como estaba en el antiguo.
Intenta actualizar el mismo archivo varias veces por segundo y comparte tus sensaciones.
2) Ya lo he explicado. Cada indicador debe trabajar con sus propios objetos gráficos. Por supuesto, tenemos que comprobar la existencia de los objetos y si ya existen, tenemos que añadir 1 al nombre del objeto.
¿Qué tiene que ver esto con añadir el 1 al nombre? Se trata de que haya objetos gráficos del mismo indicador pero diferentes copias del mismo en la pantalla al mismo tiempo. Técnicamente no existe ningún conflicto. Habrá un conflicto para el usuario que vea el chagrin en la pantalla hasta que se borre la copia antigua.
3) Bueno, ya has escrito que es solucionable.
Esto no es un problema en absoluto. Este es el funcionamiento normal del programa: creación de objetos únicos, guardado periódico de la información acumulada, limpieza tras la finalización.