Secuencia de ejecución de Init() y DeInit() - página 4
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
En Deinit, escribe todos los datos en los globales. Establece una de las globales como semáforo a través deGlobalVariableSetOnCondition.
En Init write que si el semáforo está en estado "data dumped" leeremos y trabajaremos poniendo el semáforo en estado "read all".
Si el semáforo es "ininteligible" entonces simplemente esperamos el semáforo (ya sea a través de un bucle Sleep o OnTimer).
Si no hay ningún semáforo significa que arrancamos por primera vez y contamos todo y al mismo tiempo creamos un semáforo para el cambio no futuro del TF.
¿Qué tiene de complicado una aplicación de este tipo? Prescribir una vez con una biblioteca y ya está.
Si el sueño funcionara en indicadores, sería más fácil. El sueño no funciona en los indicadores.
Si se multiplica el número de personas pequeñas, que -cada una por su cuenta, una y otra vez- van a resolver un problema común, entonces las horas de trabajo desperdiciadas muchas veces (en el límite, un número infinito de veces ;-)) superan el tiempo necesario para cualquier variante de edición en el propio terminal. Incluso la presencia de una hipotética biblioteca no garantiza que todo el mundo conozca su existencia y necesite utilizarla. En general, no está claro por qué hacer y dejar tal "rastrillo"?
Así que no es un rastrillo, es un comportamiento lógico cuando la nueva copia del indicador no conoce la anterior. ¡Esto es lógico!
Pero MILES de personas quieren una funcionalidad adicional para que la copia sí sepa. Entonces, ¿qué impide que estas unidades escriban una solución una vez y la utilicen?
Por qué fingir que se preocupan por los demás. Quien realmente lo necesite, buscará primero una solución. Y si no lo hacen, intentarán escribir uno. Una base de código centralizada sirve precisamente para eso.
Si el sueño funcionara en los indicadores, sería más fácil. El sueño no funciona en los indicadores.
Así que no es un rastrillo, es un comportamiento lógico cuando la nueva copia del indicador no conoce la anterior. ¡Esto es lógico!
Pero MILES de personas quieren una funcionalidad adicional para que la copia sí sepa. Entonces, ¿qué impide que estas unidades escriban una solución una vez y la utilicen?
Por qué fingir que se preocupan por los demás. Quien realmente lo necesite, buscará primero una solución. Y si no lo hacen, intentarán escribir uno. Un kodobase centralizado sirve precisamente para eso.
No, no es tan sencillo. Los indicadores están dentro de otra entidad - un gráfico/carta, y están subordinados a ella (soy consciente de su compleja relación uno-a-muchos, pero no cambia la esencia). Un gráfico tiene su propio ciclo de vida, que incluye algún tipo de eventos internos de init y deinit, que son los límites del ciclo de vida de los indicadores. En otras palabras, un indicador no puede sobrevivir a su gráfico. El deinit del gráfico debe esperar al deinit o al timeout del deinit de todos los indicadores. Sólo entonces se puede iniciar el init del gráfico para el nuevo marco temporal, y desde él se pueden llamar los inits de los indicadores adjuntos.
Un rastrillo es, por definición, algo que se puede pisar. Ya se ha pisado. Los buenos programas informáticos no permiten, en principio, el rastrillo.
Así que no es un rastrillo, es un comportamiento lógico cuando la nueva copia del indicador no conoce la anterior. ¡Esto es lógico!
Pero MILES de personas quieren una funcionalidad adicional para que la copia sí sepa. Entonces, ¿qué impide que estas unidades escriban una solución una vez y la utilicen?
Por qué fingir que se preocupan por los demás. Quien realmente lo necesite, buscará primero una solución. Y si no lo hacen, intentarán escribir uno. Un kodobase centralizado sirve precisamente para lo mismo.
¿Cómo es que no se sabe cuando se cambia de plazo y se introducen de nuevo los parámetros de entrada?
Y entonces Deinit terminará su trabajo y lo estropeará todo. No tiene sentido un Init y Deinit regular si haces tu propio Init y Deinit personalizado.
Yo también me he encontrado con este problema. (
Ya lohe contado todo, pero añadiré algo más de mi parte.
La peculiaridad de todos los programas para la MT es que funcionan en base a eventos. Los OnInit y OnDeinit funcionan de forma bastante lógica y adecuada según el modelo de eventos.
Pero hay un matiz extraño en el comportamiento de las variables de entrada: todos los indicadores básicos, incluidos los internos de la terminal y los que se incluyen en la entrega estándar, se inician cada vez con los mismos parámetros de entrada que han sido llamados desde el inicio anterior. Es muy conveniente. Pero no hay tal cosa para los indicadores personalizados y todos los Asesores Expertos y scripts incluyendo los estándar, esto es un inconveniente(deseo a MQ: añadir el mismo comportamiento para las variables de entrada como para los indicadores estándar).
Y lo que concierne al trabajo con Init y Deinit, así que, personalmente, nunca me puse sobre las razones de la desinicialización de los programas cuando se trabaja con las variables globales del programa, siempre construyo la lógica bajo la idea específica del programa. Por ejemplo, muy a menudo es necesario guardar las variables globales de un programa después de la desinicialización de un EA (las razones pueden ser diferentes, por ejemplo, la misma desconexión provoca OnDeinit y el posterior OnInit), así que ¿por qué para esto todo de nuevo para volver a calcular y crear nuevos indicadores maneja, etc.?
Es por eso que, como escribí antes y fxsaber, si usted necesita para guardar las variables globales de un programa en algunos casos - usted puede hacerlo en las variables globales de la terminal utilizando las banderas adecuadas.
Lamentablemente, no todo es fluido en MQL, pero el trabajo de OnInit y Ondeinit es lógico y comprensible, por lo que es una pérdida de tiempo).
¿Cómo que no sabes, cuando cambias de plazo vuelves a introducir los parámetros de entrada?
Pero el funcionamiento de OnInit y Ondeinit es lógico y comprensible, así que no hay que darle importancia).
Por favor, explique la lógica de la secuencia de OnInit y OnDeinit en el indicador cuando cambia el marco temporal. Se lo agradecería mucho. Y creo que no soy el único.
Por favor, explique la lógica de la secuencia de las operaciones OnInit y OnDeinit en el indicador cuando cambia el marco temporal. Le estaría muy agradecido. Y creo que no soy el único.
El Sr. Slava lo dijo claramente.
Se crea una copia del indicador y el antiguo se descarga después de algún tiempo.
Si queremos guardar las variables globales del programa, debemos ocuparnos de ello ya de antemano en el momento de llamar a OnInit (las variables globales del terminal cliente son buenas para este propósito).
Y los buffers de los indicadores se recalcularán de todos modos, porque las barras (velas) han cambiado, aparentemente, por eso sucede así (la copia se iniciará y la instancia anterior del indicador será terminada por la terminal).
Si el desarrollador del indicador ve el problema en el trabajo con los objetos gráficos, entonces al inicio del indicador es necesario atar los nombres de los objetos gráficos al nombre de TF, entonces la nueva copia del indicador creará nuevos objetos, y la copia anterior del indicador limpiará los antiguos.
No hay ningún problema.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Secuencia de ejecución de Init() y DeInit()
Slawa, 2017.04.07 15:31
¿Qué tipo de lógica desordena?
Cuando se cambia de marco temporal, se crea una nueva copia del indicador, que no sabe nada de la copia anterior. Durante un tiempo (muy corto) ambas copias del indicador existen en paralelo. Entonces se descarga la copia anterior.
Lea la documentación https://www.mql5.com/ru/docs/runtime/running
El Sr. Slava lo dijo claramente.
Se crea una copia del indicador y el antiguo se descarga después de algún tiempo.
Si queremos guardar las variables globales del programa, debemos ocuparnos de ello ya de antemano en el momento de llamar a OnInit (las variables globales del terminal cliente son buenas para este propósito).
Y los buffers de los indicadores se recalcularán de todos modos, porque las barras (velas) han cambiado, aparentemente, por eso sucede así (la copia se iniciará y la instancia anterior del indicador será terminada por la terminal).
Si el desarrollador del indicador ve el problema en el trabajo con los objetos gráficos, entonces cuando inicie el indicador, debe atar los nombres de los objetos gráficos al nombre de TF, entonces la nueva copia del indicador creará nuevos objetos, y la copia anterior del indicador limpiará sus datos.
No hay ningún problema.
Sí, está claro. Preguntaba por la lógica de la secuencia de ejecución. La cuestión es que no existe tal lógica. A veces se ejecuta primero OnDeinit (como debería ser según la lógica del hombre común), y a veces se ejecuta primero OnInit.
Entiendo que la respuesta está en la observación"Durante un cierto periodo de tiempo (un tiempo muy corto) ambas copias del indicador existen en paralelo". Pero esto no aclara la cuestión.