Secuencia de ejecución de Init() y DeInit() - página 3
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
Intenta actualizar el terminal a la versión 1065. Las versiones anteriores daban un error de reinicialización con sólo cambiar el marco temporal. Podría ayudar :)
https://www.mql5.com/ru/forum/187690
Tengo el terminal 5.00 b1571
Podrías guardar los valores de las variables en algún lugar, en globals por ejemplo. Después de haberlas traducido, podrías leer y restaurar las variables.
Y entonces Deinit terminará su trabajo y lo estropeará todo. No tiene sentido un Init y Deinit regular si para hacer su propio Init y Deinit personalizado.
Yo también me he encontrado con este problema. (
Y entonces Deinit terminará su trabajo y arruinará 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. (
Estoy completamente de acuerdo (No tiene sentido el Init y el Deinit regulares)
Tal vez intente asignar a los objetos gráficos un punto TF como parte del prefijo de su nombre,
y luego aplicar algo como esto:
Sí tuvo que hacer algo así, pero es una solución parcial.
Se puede hacer lo mismo con las variables a través de un recurso o archivos, pero esto es un recurso adicional aparte, que se podría haber evitado arreglando MT5
Abarrotar el código con funciones secundarias innecesarias, comprobaciones, etc. (SIN....)
Siempre he pensado (resulta que en vano), que cuando cambio de TF, primero desinito en el antiguo TF y luego Init en el nuevo. Este es un curso lógico de los acontecimientos. Me basé en esta lógica al desarrollar Asesores Expertos e indicadores. Y ahora resulta ser un verdadero disparate con eventos que interrumpen la secuencia de los acontecimientos...
A veces notaba que algo iba mal con los cuadros y objetos gráficos y tenía que cambiar de TF varias veces para ver que todo se mostraba correctamente.
Ahora son los códigos en los que algo en deinites cambia y luego inites también vuelve a cambiar... ¡¡¡y resulta que la secuencia se invierte!!! Es una lógica horrible. ¿A quién se le ocurrió esto?
Lo primero que se me ocurre es que en mi deinit el estado anterior (botones pulsados/liberados) se almacena en las variables globales y luego los botones se establecen según los valores guardados en los inits. Y son los botones los que no siempre se reinician correctamente. Esto es lo primero que recordé, tal vez encuentre algo más... mañana investigaré por ahí.
Gracias a los desarrolladores, que se han esforzado mucho...
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á.
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 "ilegible" entonces simplemente esperamos a que el semáforo regrese (ya sea a través de los bucles Sleep u OnTimer).
¿Qué tiene de complicado una aplicación de este tipo? Escribirlo una vez en la biblioteca y ya está.
No sabía que existiera tal problema. Esperaba una secuencia deiniti-init y no al revés. Cuando conoces los problemas, puedes resolverlos. Pero me parece que debería resolverse a nivel de la lógica de los terminales y no con muletas, que deberían introducirse en todos los programas ahora...
No se trata de una muleta, sino de una solución sencilla. La única cuestión es quién la aplica: los desarrolladores o los usuarios. En ambos casos hay que dedicar tiempo y escribirlo una vez. Si los usuarios pueden hacerlo, lo escribimos y no nos molestamos en seguir discutiendo la cuestión. Acabo de leer el hilo y se me ha ocurrido una solución enseguida. ¿Qué hay que estudiar? Puedes exigir algo durante mucho tiempo, o puedes escribirlo rápidamente tú mismo.