Secuencia de ejecución de Init() y DeInit() - página 5
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
Lo entiendo. Preguntaba por la lógica de la secuencia de operaciones. Y aquí nos lo perdemos. A veces se ejecuta primero OnDeinit (como debería ser según la lógica de un profano) y a veces se ejecuta primero OnInit.
Entiendo que la respuesta está en la línea"Durante algún tiempo (un tiempo muy corto) ambas copias del indicador existen en paralelo." Pero esto no aclara la cuestión.
La función OnInit debe ejecutarse primero en el programa.
¿Puede dar un ejemplo cuando la secuencia OnInit -> OnDeinit no se ejecuta siempre?
Se supone que la función OnInit se ejecuta primero en el programa.
¿Puede dar un ejemplo cuando OnInit -> OnDeinit no se ejecuta siempre?
Puedes usar un ejemplo del autor del temaERROR.mq5, que da al principio. Cambia el TF y mira lo que ocurre en la pestaña de Expertos.
Puedes utilizar el ejemploERROR.mq5 que da al principio
Lo probaré a lo largo del día. ¿Ya lo has utilizado personalmente?
Por supuesto, lo usé hace 9 meses. Puedes leer mi comentario en el número 8 de este hilo.
No, no es tan sencillo. Los indicadores se encuentran dentro de otra entidad, el gráfico, y están subordinados a él (soy consciente de su compleja relación de uno a muchos, pero eso no cambia la cuestión). 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 tiempo de espera 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.
Los gráficos son lo mismo que los indicadores. Los indicadores pueden "sobrevivir" a sus gráficos.
Antes del OnInit de un indicador/asesor, se ejecutan los constructores de los objetos globales. Después de OnDeinit - los destructores. Por lo tanto, puede eliminar OnInit y OnDeinit de cualquier indicador.
El único problema es que no coinciden sus ideas sobre los indicadores con la realidad. Quizás, este comportamiento es crítico para algunos autónomos que no pueden escribir la solución.
Me gustaría que los desarrolladores dieran un paso adelante en este tema. Pero aquí chocan dos puntos de vista completamente comprensibles con su propia lógica, como debe ser. Ninguno de ellos es más defectuoso que el otro. Lo que pasa es que unos piensan que está bien así y otros que está bien así.
Imagina lo lentos que serían los gráficos si antes de cambiar el TF el terminal esperara a que se descarguen todos los indicadores del antiguo TF y sólo entonces construyera e inicializara el nuevo.
¿En qué situaciones, además del trabajo directo con objetos gráficos (sin el nombre de TF en el nombre) es importante la secuencia DeInit - Init?
Imagina lo lentos que serían los gráficos si antes de cambiar el TF el terminal esperara a que se descarguen todos los indicadores del antiguo TF y sólo entonces construyera e inicializara el nuevo.
¿En qué situaciones, además del trabajo directo con objetos gráficos (sin el nombre de TF en el nombre) es importante la secuencia DeInit - Init?
+
Una vez más. Cuando se cambia de marco temporal o de símbolo en el gráfico, se crea una nueva copia del indicador. Una nueva.
Por la misma razón que las partes calculadas de los indicadores viven en los cachés de la historia. Para cada marco temporal tiene su propio caché de barras. Cuando se cambia de timeframe, digamos EURUSD,M1 en EURUSD,H1, al indicador en la caché M1 se le envía el evento Deinit con causa 3 (cambio de gráfico) y después de un tiempo este indicador se descargará. Si de repente este indicador no tuvo tiempo de manejar el Deinit con la razón 3, será desinicializado con la razón 1 (cierre del gráfico). Si la caché H1 no existía en ese momento, se creará. Después, la copia del indicador NEW se carga en la caché H1, a la que se envía el evento Init. La nueva copia del indicador no sabe nada de la copia anterior, que está a punto de morir. Todas las variables de la nueva copia del indicador están limpias, son recién nacidas.
Si hay un cambio de marco temporal dentro de un mismo símbolo, el orden de inicialización/desinicialización es en principio predecible. Descargue la última versión 1580 - hemos corregido algunas cosas, ahora la eliminación de los indicadores se realiza en el último turno, por lo que no debería haber una desiniteración prematura. Pero si se cambia un símbolo, se obtiene una carrera entre hilos de forma pura, y no se puede predecir la secuencia de inicialización-deinicialización de forma inequívoca. Dado que los diferentes caracteres se procesan en diferentes hilos
Por lo tanto, un consejo para el inicio del tema. Centrarse en la causa de la desinicialización. Si es 3, no es necesario devolver el esquema de colores al gráfico
Imagina lo lentos que serían los gráficos si antes de cambiar el TF el terminal esperara a que se descarguen todos los indicadores del antiguo TF y sólo entonces construyera e inicializara el nuevo.
¿En qué situaciones, aparte del trabajo directo con objetos gráficos (sin el nombre de TF en el nombre) es importante la secuencia DeInit - Init?
¿Por qué iban a ser lentos? A menos que el indicador esté mal escrito. Para un indicador bien escrito, DeInit tarda muy poco tiempo. Además, el cambio de TF no es una operación tan frecuente. En algunos casos especialmente graves (para indicadores "erróneos") se puede esperar uno o dos segundos al cambiar de TF.
Por lo tanto, el argumento sobre el frenado durante el cambio de TF es más que dudoso. Además, cuando se pasa a la TF que aún no se ha construido, el retraso es bastante palpable. Y nadie llora por los frenos de la terminal.