Secuencia de ejecución de Init() y DeInit() - página 10
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
He escrito claramente - mantener los datos necesarios para transferir a la copia siempre al día, no es necesario hacerlo sólo cuando initing, siempre mantenerlo al día.
Andrey, ¿estás bromeando o realmente no entiendes que todos tus datos reales almacenados en variables y matrices en los indicadores se vuelven irrelevantes después del cambio de TF porque la copia del indicador con todos sus detalles se elimina. En los Asesores Expertos, por supuesto, todo es sencillo, porque no hay reinicialización.
Debes estar bromeando o no entiendes que todos tus datos reales almacenados en variables y arrays en los indicadores se vuelven irrelevantes después del cambio de TF porque la copia del indicador con todos sus detalles se borra. En Expertos, por supuesto, todo es sencillo, porque no hay reinicialización.
No, no lo estoy.
No entiendes lo que digo.
Por ejemplo, hay un determinado conjunto de datos que necesita ser transferido a otra copia del indicador (ya sea otro indicador lanzado en un gráfico o una nueva copia del indicador cuando el TF cambia, no importa). El indicador calcula algo y cada vez que calcula algo y este algo se aplicará a otros indicadores, este indicador debe actualizarse. Cada vez. Esta base de datos puede almacenarse en diferentes lugares, dependiendo de la cantidad de datos y de la velocidad de transferencia de datos necesaria. Estos datos deben actualizarse siempre que sea necesario después de realizar un cambio en los datos, no sólo cuando se desinicialicen. Ese es el truco. No hay nada complicado en ello. No se trata de almacenar los datos en las variables locales del indicador, se trata de restablecer/actualizar los datos cada vez que los datos han sido recalculados.
Pero con los objetos gráficos es muy sencillo.
En los Asesores Expertos, por supuesto, todo es sencillo, porque no hay reinicialización.
No, no lo estoy.
No entiendes lo que digo.
Por ejemplo, hay un determinado conjunto de datos que necesita ser transferido a otra copia del indicador (ya sea otro indicador lanzado en un gráfico o una nueva copia del indicador cuando el TF cambia, no importa). El indicador calcula algo y cada vez que calcula algo y este algo se aplicará a otros indicadores, este indicador debe actualizarse. Cada vez. Esta base de datos puede almacenarse en diferentes lugares, en función de la cantidad de datos y de la velocidad de transferencia de datos necesaria. Estos datos deben actualizarse siempre que sea necesario después de realizar un cambio en los datos, no sólo cuando se desinicialicen. Ese es el truco. No hay nada complicado en ello. No se trata de almacenar los datos en las variables locales del indicador, se trata de restablecer/actualizar los datos cada vez que los datos han sido recalculados.
Y con los objetos gráficos es muy sencillo, no hace falta ni explicarlo.
Es muy discutible que nada sea complicado. Trata de replicar realmente en el ejemplo de una simple máquina onduladora lo que he implementado en este producto. En la rueda de muñeca se cambia el periodo con el ratón y luego, cuando se cambia de TF, los cambios se deben guardar, y se pueden utilizar varios indicadores en la ventana. Y verás que no hay nada complicado. Y si necesitas pasar un array Y verás lo "sencillo" que es. Tal vez yo mismo lo pensaría, si no lo hubiera puesto ya en práctica.
Es muy discutible que nada sea difícil. Intenta replicar realmente en el ejemplo de un simple demoledor lo que he implementado en este producto. En la rueda de muñeca se cambia el periodo con el ratón, y luego, cuando se cambia de TF, los cambios deben guardarse, y es posible utilizar varios indicadores en la ventana. Y verás que no hay nada complicado. Y si necesitas pasar un array Y verás lo "sencillo" que es.
Recientemente he aprendido que todas las variables de los EAs se conservan durante la reinicialización, es decir, escribí los EAs de la misma manera que los indicadores, asumiendo que el programa no sabe nada de otros programas, ya que sólo existe su init y deinit, el programa no debe saber sobre el init y deinit de otros programas.
Por eso nunca me fío de la consistencia temporal del ininit y deinit del programa para ser descargado y ejecutado de nuevo, antes no me fiaba de que pueda cambiar alguna vez (en 1580 ha cambiado). Confiar en los errores no documentados y en los futuros de la plataforma puede ser contraproducente en el futuro.
En mi práctica, también hay productos que cambian dinámicamente la visualización en función de las acciones del usuario, aplicando todo, desde eventos hasta archivos de intercambio. Hay muchos más indicadores en el gráfico que en el 1 como norma, los buffers de indicadores en el 5 son ilimitados y puedes crearlos como parámetro durante el arranque. Es decir, somos personas creativas, tenemos que tener un enfoque flexible para resolver nuestras tareas y al mismo tiempo tener en cuenta las especificidades de 3 tipos de programas, pero los desarrolladores de plataformas se preocupan por otras cuestiones, que son más importantes que las dificultades menores en comparación con las tareas globales de la plataforma.
Hay defectos realmente importantes en la plataforma, de los que no se habla mucho o nada, es mucho más importante que el rebuscado problema del "orden inits y deinits".
Si el marco temporal se cambia a la baja, OnInit en el marco temporal más bajo (nuevo) primero y luego OnDeinit en el marco temporal más alto (antiguo).
Si el interruptor va hacia arriba, entonces es viceversa. Primero OnDeinit en el marco temporal inferior (antiguo), y luego OnInit en el marco temporal superior (nuevo).
Aquí debemos tener en cuenta que las cachés se procesan de menor a mayor plazo
Esto es simplemente horrible. Los programadores de aplicaciones no deben pensar en esas cosas sistémicas. La plataforma puede manejar los cachés internamente como quiera, pero a nivel de MQL debe llevar todo de forma transparente a un único contrato de eventos, sin potenciales efectos secundarios. Todas las referencias a supuestas consideraciones de eficiencia y a la posibilidad de que cada uno solucione el problema por sí mismo son sencillamente insostenibles. Es posible hacer ambas cosas de forma eficaz y cómoda (eliminando la posibilidad de pisar este rastrillo por completo), de una vez por todas.
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?
La preocupación del SO es que el CT no interfiera con otros CT y lo que hagan allí en la RAM, intercambiar archivos o lo que sea es asunto suyo.
"¡Creo que sí!" (c) Mimino, 1977.
Me gustaría resumir y sintetizar lo anterior. Entonces, antes del lanzamiento de la build 1580 de MT5 (actual build 1571), ¿qué tenemos?
En los indicadores, a diferencia de los Asesores Expertos, cuando el TF cambia, debido a que"se crea una nueva copia del indicador, que no sabe nada de la copia anterior", se reinicializan todas las variables, además de que el orden de ejecución de OnDeinit del antiguo TF y OnInit del nuevo TF es impredecible, independientemente de que el TF esté "arriba" o "abajo" (práctica, contraria a lo mencionado por el Sr. Slava). En este sentido, los programadores tienen una serie de problemas e incertidumbres. Por ejemplo:
- el programador, que no ha leído este tema, crea un objeto para algo en OnInit, comprobando lógicamente antes de la creación del indicador la existencia de un objeto con este nombre. También es lógico prescribir la eliminación de este objeto en OnDeinit. Cuando se cambia el TF, si primero se ejecuta el OnInit del nuevo TF, se comprueba la existencia del objeto, resulta que ya existe, y no se crea, porque ya está creado. Después se realiza el OnDeinit de la antigua TF y se elimina el objeto. El programador está en estado de shock. ¿Dónde está mi objeto y por qué ha desaparecido? Se confundirá aún más, cuando la próxima vez que se cambie el TF, cuando la secuencia de OnInit y OnDeinit sea diferente, el objeto no se elimine. Está borrado, no está borrado.... Después de una larga investigación comenzará a dirigirse a Service Desk, nuevos hilos en el foro sobre la antigua.
Esta es sólo la situación más sencilla. Habrá otros, ya que esta característica no está descrita en la documentación y sólo se puede leer sobre ella en el foro.
Si quieres crear algo especial y pasar algunos parámetros de la copia antigua del indicador a la nueva, cuando cambies el TF, no puedes usar OnDeinit, debido a la secuencia impredecible de las operaciones de inicialización y desinicialización. En miopinión, la mejor solución en este caso es utilizar las siguientes herramientas:ResourceCreate basado en el array de píxeles yResourceReadImage, pero es bastante engorroso y hay que tener cuidado con el conflicto de recursos, si se utilizan varios indicadores idénticos en una ventana, y cada vez que los datos que se quieren enviar para otra copia hay que guardarlos en un recurso no reinicializado, porque el tiempo de posible cambio de TF no es conocido para la aplicación. He implementado esto hace mucho tiempo (por ejemplo, en este producto), así que sé de lo que estoy hablando. La implementación de la transferencia de datos a través de archivos y variables globales de la terminal es una solución menos exitosa (IMHO).
Si la nueva compilación 1580 serácomo dice Slava, no facilitará la tarea, porque la desinicialización de la vieja copia del indicador se realizará después de la inicialización de una nueva. Pero no habrá incertidumbre.
Tenemos que esperar que los desarrolladores hayan prestado atención a este problema, ya que están tratando de solucionarlo.
Estamos esperando una nueva construcción.
Estoy completamente de acuerdo en que esta característica de procesamiento DEBE mencionarse en la documentación, de lo contrario los recién llegados se enfrentarán a este problema y acudirán a los foros en busca de una solución. (¿Por qué, cuando se puede decir de inmediato en la Terminal y MQL docs).
También hay que añadir a la documentación que el registro no muestra una imagen completa de los eventos, sino sólo una parte. Consulte los registros completos para ver el panorama completo.
Sobre el resto más tarde ...
Me gustaría resumir y sintetizar lo anterior. Entonces, antes del lanzamiento de la build 1580 de MT5 (actual build 1571), ¿qué tenemos?
En los indicadores, a diferencia de los Asesores Expertos, cuando el TF cambia, debido a que"se crea una nueva copia del indicador, que no sabe nada de la copia anterior", se reinicializan todas las variables, además de que el orden de ejecución de OnDeinit del antiguo TF y OnInit del nuevo TF es impredecible, independientemente de que el TF esté "arriba" o "abajo" (práctica, contraria a lo mencionado por el Sr. Slava). En este sentido, los programadores tienen una serie de problemas e incertidumbres. Por ejemplo:
- el programador, que no ha leído este tema al crear un indicador para algo en OnInit, crea un objeto, lógicamente comprobando antes la creación del objeto con este nombre. También es lógico prescribir la eliminación de este objeto en OnDeinit. Cuando se cambia el TF, si primero se ejecuta el OnInit del nuevo TF, se comprueba la existencia del objeto, resulta que ya existe, y no se crea, porque ya está creado. Luego se realiza el OnDeinit del antiguo TF y se elimina el objeto. El programador está en estado de shock. ¿Dónde está mi objeto y por qué ha desaparecido? Se confundirá aún más, cuando la próxima vez que se cambie el TF, cuando la secuencia de OnInit y OnDeinit sea diferente, el objeto no se elimine. Está borrado, no está borrado.... Después de una larga investigación comenzará a dirigirse a Service Desk, nuevos hilos en el foro sobre el antiguo.
Esta es sólo la situación más sencilla. Habrá otros, ya que esta característica no está descrita en la documentación y sólo se puede leer sobre ella en el foro.
Si quieres crear algo especial y pasar algunos parámetros de la copia antigua del indicador a la nueva, cuando cambies el TF, no puedes usar OnDeinit, debido a la secuencia impredecible de las operaciones de inicialización y desinicialización. En miopinión, la mejor solución en este caso es utilizar las siguientes herramientas:ResourceCreate basado en el array de píxeles yResourceReadImage, pero es bastante engorroso y hay que tener cuidado con el conflicto de recursos, si se utilizan varios indicadores idénticos en una ventana, y cada vez que los datos que se quieren enviar para otra copia hay que guardarlos en un recurso no reinicializado, porque el tiempo de posible cambio de TF no es conocido para la aplicación. He implementado esto hace mucho tiempo (por ejemplo, en este producto), así que sé de lo que estoy hablando. La implementación de la transferencia de datos a través de archivos y variables globales de la terminal es una solución menos exitosa (IMHO).
Si la nueva compilación 1580 serácomo dice Slava, no facilitará la tarea, porque la desinicialización de la antigua copia del indicador se realizará después de la inicialización de una nueva. Pero al menos no habrá incertidumbre.
Espero que los desarrolladores hayan prestado atención a este problema ya que intentan solucionarlo.
Estamos esperando una nueva construcción.
El Asesor Experto funciona bien cuando se cambia el TF, y el indicador en esta situación funciona de manera muy diferente.
No hay problema si se conoce esta característica indocumentada y sólo se trata del caso más simple, el gráfico. objetos. Me refiero a los que no conocen esta característica, creo que este tema en este foro lo leerá un porcentaje muy pequeño de programadores y me da pena su tiempo para averiguar todos los matices. Ya había estado en esta situación antes de comprender la esencia.