Necesito ayuda de los desarrolladores y programadores de MT4 - página 7

Nuevo comentario
 

Qué montón de basura...

También creo que hacer un bucle con el EA es una mauvais ton. Cambiar los parámetros sólo después del final del ciclo de arranque es perfectamente lógico. El tópico no pudo evitar entender que el problema está en su bucle infinito, ya que no es un aficionado. Sin embargo, no ha escrito nada en el primer post sobre el bucle infinito en el Asesor Experto. Personalmente no he implementado este tipo de sistemas en mis EAs, pero a mi entender, a juzgar por mis posts, no haocurrido antes- la ventana de parámetros en los EAs en bucle simplemente no se abrió. Esto significa que la afirmación del TC"Lleva a una incompatibilidad fundamental de los EAs existentes con las nuevas buildsde MT4." no es cierta - en las antiguas builds de MT4, tales EAs tampoco permitían cambiar los parámetros, porque era imposible abrir la ventana hasta el final del ciclo.

EventSetMillisecondTimer resuelve el problema. Pero, ¿cuánto tiempo hace que apareció esta función? ¿No había antes sólo EventSetTimer? Con un intervalo de llamada mínimo de 1 segundo, tal evento es completamente inútil cuando se escriben sistemas para el comercio real, cuando puede haber docenas de ticks para cada símbolo por segundo.

Todavía no hay ninguna referencia a esta función enla ayuda de los temporizadores. Lo he descubierto por casualidad, como una pista al entrar en el EventSet.

 
Sin embargo, hay, en mi opinión, con respecto a la inicialización de las variables, un problema y una incoherencia en el nuevo MQL 4/5: Cuando la desinicialización y la inicialización no borrar y volver a crear objetos dinámicos en las variables globales. Es decir, si los parámetros del EA se leen en los constructores de los objetos creados dinámicamente en variables globales y el EA sigue trabajando con ellos, cuando los parámetros se cambien, el EA seguirá trabajando como si los parámetros no hubieran cambiado. En mi opinión, no es lógico y las variables globales deberían ser desinicializadas después de la desinicialización del EA y luego reinicializadas antes de la inicialización del EA. Esto se resuelve actualmente poniendo la inicialización y el borrado de dichas variables en OnInit y OnDeinit
 
AntFX:
Sin embargo, hay, en mi opinión, un problema y una incoherencia en el nuevo MQL 4/5: Al desinicializar e inicializar no se borran y se vuelven a crear objetos dinámicos en las variables globales...
Este es un buen punto... pero aparentemente el desarrollador decidió que sólo el "nacimiento" y la "muerte" del programa pueden afectar al valor inicial de las variables globales... así que en el bloque de desinicialización tenemos que poner a cero los valores de las variables globales o asignarles valores iniciales ....
 
AntFX:
Sin embargo, hay, en mi opinión, un problema y una incoherencia en el nuevo MQL 4/5: la desinicialización y la inicialización no eliminan y vuelven a crear objetos dinámicos en las variables globales. Es decir, si los parámetros del EA se leen en los constructores de los objetos creados dinámicamente en variables globales y el EA sigue trabajando con ellos, cuando los parámetros se cambien, el EA seguirá trabajando como si los parámetros no hubieran cambiado. En mi opinión, no es lógico y las variables globales deberían ser desinicializadas después de la desinicialización del EA y luego reinicializadas antes de la inicialización del EA. Esto se resuelve actualmente poniendo la inicialización y el borrado de dichas variables en OnInit y OnDeinit

Sí, es un auténtico chanchullo, sobre todo teniendo en cuenta que la documentación (niaquí niaquí) no hace hincapié en que ahora la carga no está vinculada 1 a 1 con el evento de inicialización. Aquí hay algunas palabras como esta:

Las variables globales se inicializan una vez inmediatamente después de cargar el programa en la memoria del terminal cliente.

es claramente insuficiente para señalar al desarrollador que los cambios de parámetros posteriores serán desinicializados e inicializados, PERO NO la correspondiente descarga y carga.

 
marketeer:

Sí, es un auténtico chanchullo, sobre todo teniendo en cuenta que la documentación (niaquí niaquí) no hace hincapié en que ahora la carga no está vinculada 1 a 1 con el evento de inicialización. Aquí hay algunas palabras como esta:

Las variables globales se inicializan una vez inmediatamente después de cargar el programa en la memoria del terminal cliente.

obviamente no es suficiente para llamar la atención del desarrollador sobre el hecho de que los cambios de parámetros posteriores desinicializarán e inicializarán, pero NO realizarán la correspondiente descarga y carga.

No es necesario cargar/descargar y reinicializar las variables. El programador debe encargarse de la inicialización de las variables.

 
Contender:

No es necesario cargar/descargar y reinicializar las variables. El programador debe encargarse de la inicialización de las variables.

A eso me refiero: no está claro cuándo se realiza esta inicialización. Código con una variable global:

int x = 0;

esto también es la inicialización. Pero no está claramente escrito en la documentación que esto no es sólo la inicialización desde el punto de vista de MC.

 
Estrictamente hablando, ahora hay 2 inicializaciones diferentes en MT: una realizada cuando se carga el programa, y otra cuando se cambia el "entorno" al llamar a OnInit. Ya es bastante malo que esto tenga que ser desenterrado.
 
marketeer:
Estrictamente hablando, ahora hay 2 inicializaciones diferentes en MT: una se realiza al inicio del programa y la otra se realiza al cambiar el "entorno" en el momento de la llamada OnInit. Lo malo es que hay que desenterrarlo.

El arranque en frío se realiza al iniciar el programa. La memoria se asigna a las variables y se inicializa con valores iniciales.

En marcha - arranque en caliente. Aquí el programador tiene que ocuparse de la inicialización de las variables y esto es bueno.

 
Contender:

El arranque en frío se realiza al iniciar el programa. La memoria se asigna a las variables y se inicializa con valores iniciales.

En marcha - arranque en caliente. En este caso, el programador tiene que ocuparse de la inicialización de las variables y esto es bueno.

Bueno o malo, es una cuestión filosófica... Pero el hecho de que haya 0,0 información al respecto en la Documentación no es bueno...
 
denkir:
Si es bueno o malo es una cuestión filosófica... Pero el hecho de que haya 0,0 información al respecto en la Documentación no es bueno...

Y, si no recuerdo mal, antes no existía, es decir, es, por decirlo suavemente, una "característica" añadida especialmente para "comodidad" de los programadores, pero que viola la invariabilidad de los códigos existentes (escritos para las reglas de inicialización anteriores). Así, no se respeta el principio inmutable de preservar la compatibilidad del código antiguo con las nuevas versiones de software siempre que sea posible.

Nadie está en contra de las nuevas características y optimizaciones. Pero, ¿por qué no hacerlo de forma que no se rompa el código antiguo? En particular, para esta nueva inicialización podríamos asignar un comando de preprocesador adicional similar a #property strict. Por ejemplo, podría ser #property lazyinit, y si es especificado por el desarrollador (es decir, explícitamente, lo que significa que es consciente de la nueva inicialización en mql), entonces nos alegramos de la optimización optimizada. Y si no se especifica, entonces nos alegramos de que el código anterior funcione de forma consistente, sin tener que escarbar y buscar lugares donde puedan quedar las variables globales, que ahora no sólo tienen que ser declaradas, sino también inicializadas por separado en OnInit. Para cada una de estas variables, habrá 2 líneas de código en lugar de una.

12345678
Nuevo comentario