Secuencia de ejecución de Init() y DeInit() - página 6
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
¿Por qué iban a ser lentos? A menos que el indicador esté mal escrito. Un indicador de DeInit bien escrito lleva bastante 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 pasamos a la TF que aún no se ha construido, también nos encontramos con un retraso de tiempo bastante apreciable. Y nadie llora por los frenos del terminal.
Los indicadores son diferentes. También los hay lentos. Y no todas son propias y en código fuente.
Me divierte un par de segundos. Siento decenas de milisegundos en la interfaz, siento molestias de inmediato.
Y, lo más importante, no hay respuesta a mi pregunta:
¿En qué situaciones, excepto el trabajo directo con objetos gráficos (sin el nombre TF en el título), es importante la secuencia DeInit - Init?
Hay indicadores de todas las formas y tamaños. También las frenadas. Y no todas son propias y en código fuente.
Un par de segundos es divertido. En la interfaz se sienten decenas de milisegundos, hay malestar de inmediato.
Y, lo más importante, no hay respuesta a mi pregunta:
¿En qué situaciones, aparte del trabajo directo con objetos gráficos (sin el nombre TF en el nombre), es importante la secuencia DeInit - Init?
No suelo utilizar variables globales, pero a veces ocurre.
Al trabajar con variables globales nos hacemos un lío. Cuando se elimina el indicador del gráfico es necesario limpiarlo y eliminar las variables globales. ¿En qué lugar del indicador vas a borrar las variables globales? Probablemente, debe ser eliminado en Deinite, no hay otro lugar. Así, cuando cambias de plazo y creas nuevas variables, viene Deinite y lo borra todo. Resulta que las Variables Globales no se pueden utilizar en los indicadores.
Normalmente no utilizo variables globales, pero a veces ocurre.
Cuando se trabaja con variables globales, se pica. Cuando elimine el indicador del gráfico, deberá limpiarlo y eliminar las variables globales. ¿En qué lugar del indicador vas a borrar las variables globales? Probablemente, debe ser eliminado en Deinite, no hay otro lugar. Así, cuando cambias de plazo y creas nuevas variables, viene Deinite y lo borra todo. Resulta que las Variables Globales no se pueden utilizar en los indicadores.
Sergiy, ¿tienes un ejemplo real que no esté sacado de la nada? A mí también se me ocurre un ejemplo así, pero en la práctica no me he encontrado con ningún problema.
Nota: Las variables globales también pueden ser nombradas en función de la TF.
Hay indicadores de todas las formas y tamaños. También las frenadas. Y no todas son propias y en código fuente.
Un par de segundos es divertido. La interfaz se siente decenas de milisegundos, la incomodidad aparece inmediatamente.
Y, lo más importante, no hay respuesta a mi pregunta:
¿En qué situaciones, aparte del trabajo directo con objetos gráficos (sin un nombre TF en el título), es importante la secuencia DeInit - Init?
En la página 3 di un ejemplo práctico:
memorizar en la cabeza de la terminal cada vez que se modifican las variables relevantes, no cuando ini/deinit.
recuerde en la terminal principal cada vez que se modifican las variables correspondientes, no cuando ini/deinit.
Lo recordaré)
Y también recuerde, que en la implementación actual no se puede hacer nada en Deinit que luego deba ser utilizado (ni en variables globales ni escribiendo en archivos)...
esencialmente inútil finci se ha convertido, con una secuencia tan rota.
Yo lo recordaré (menos mal que me tropecé con este hilo por casualidad), pero otros programadores (que no mirarán aquí) utilizarán la consecuencia lógica natural y usarán Deinit esperando que funcione, y entonces init se ejecutará en un nuevo TF.
Lo recordaré)
Recuerda también que la implementación actual del terminal no permite hacer nada en Deinit que deba ser utilizado posteriormente (ni en variables globales, ni en archivos)...
esencialmente un finkzi inútil, con una secuencia tan rota
Sólo hay que entender que también hay otra lógica. La lógica de los desarrolladores de MT en particular. Según esta, otra lógica, todo parece bastante lógico. De ahí la conclusión: ajústate a esta lógica y no intentes hacer cambiar de opinión a personas que probablemente tienen más experiencia que tú en esto. Es inútil... Nadie aceptará cambiar la lógica establecida por el bien de un indicador.
Si no se tratara de finanzas, tal vez no habría habido tal discusión.
Y como un asesor de operaciones depende de un indicador u otro, simplemente dejará de funcionar correctamente por un simple cambio de TF. Eso es lo más estresante.
Entonces, ¿cómo puedes confiarle tus finanzas?
Puede que estemos en desacuerdo con los desarrolladores de MT en este caso.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?
Todos ustedes están confundiendo muchas cosas diferentes. Acordemos al menos dos requisitos para el terminal como software crítico:
- debe funcionar de forma predecible, siguiendo estrictamente la misma lógica (incluso con multihilo);
- debe funcionar rápidamente.
(no es importante que la copia del indicador conozca otras copias, pero sí es importante que los datos globales, asignados para su almacenamiento al terminal, sean consistentes - esto es asunto del terminal, no de cada desarrollador de indicadores)
Además, hay una cuestión: cómo aplicarlo. Ahora se aplica teniendo en cuenta el requisito 2. Propongo que se aplique teniendo en cuenta el requisito 1, sin afectar al requisito 2.
No habrá ralentizaciones notables, si prestamos atención al hecho de que los eventos de init/deinit del gráfico e init/deinit del indicador son cosas diferentes. El gráfico mostrará inmediatamente el nuevo gráfico principal, pero para los indicadores heredados el evento OnInit se pondrá en cola después del procesamiento del OnDeinit anterior. De todos modos, los eventos se ponen en cola en el terminal.
Si MQ lo desea, puede enviarme en sus términos los gráficos NDA de las clases y secuencias, los corregiré ;-).