Errores, fallos, preguntas - página 2541

Nuevo comentario
 
Ilyas:
Así que no conseguiste devolver el control a la terminal, te "colgaste" en un bucle "infinito" dentro del Fn en la DLL.
¿De qué tipo de terminación normal estamos hablando?

Si necesita este comportamiento, debe ejecutar un hilo separado con un bucle dentro de Fn en DLL, que debe ser detenido por una bandera, que se establece en una función separada FnStop y con DLL_PROCESS_DETACH

El hecho de no recuperar el control, se hace por ejemplo, está claro que el while debe ejecutarse en un hilo separado, para no bloquear el hilo de mql.
Pero obtengo el mismo comportamiento cuando lo ejecuto estando en otro hilo, el problema está en DLL_PROCESS_DETACH, este identificador no funciona, por la bandera existente Detach.
Sí, ya hemos escrito, que necesitamos crear una función exportada por separado y utilizarla para controlar esta bandera.
Pero como se muestra en este ejemplo, la bandera en DLL_PROCESS_DETACH no funciona.
Tal vez haya un error en la terminal, es lógico que DLL_PROCESS_DETACH transfiera la bandera a otro estado.
El bucle while obtiene este estado, sale del bucle, se ejecuta cualquier cosa que se encuentre en el camino y termina la propia función Fn().
¡Sólo después de eso la dll debe ser descargada!
Pero esto no sucede, tenemos algún tipo de descarga de dlls temprana por mecanismos ocultos de la terminal, por lo que obtenemos un crash.

 
TheXpert:

No quiero que gente incompetente como tú, Fedoseyev, etc. se metan a discutir bichos y construcciones.

para que las construcciones y mecanismos tomados en MQL de C++ en su totalidad y con el mismo aspecto que en C++ funcionen igual que en C++.

es una mierda y lo sabes, pero tienes que lanzarlo ahí.

Eres tú el que se queja de lo molesto que es, de un idioma y un hilo separados.

Abre un hilo aparte para ti y tus simpatizantes y lloriquea allí.

Tenía una mejor opinión de ti. Mi error. Eso sucede. Eres grosero y ... no es inteligente.

 
Roman:

Se hace por ejemplo, mientras que debe ejecutarse en un hilo separado, para no bloquear el hilo mql.
Obtengo el mismo comportamiento cuando arranco estando en otro hilo, el problema es en DLL_PROCESS_DETACH, este identificador no funciona, por la bandera existente Detach.
Sí, ya hemos escrito, que necesitamos crear una función exportada por separado y utilizarla para controlar esta bandera.
Pero como se muestra en este ejemplo, la bandera en DLL_PROCESS_DETACH no funciona.
Tal vez haya un error en la terminal, es lógico que DLL_PROCESS_DETACH transfiera la bandera a otro estado.
El bucle while obtiene este estado, sale del bucle, se ejecuta cualquier cosa que se encuentre en el camino y termina la propia función Fn().
¡Sólo después de eso la dll debe ser descargada!
Pero esto no sucede, tenemos algún tipo de descarga de dlls temprana por mecanismos ocultos de la terminal, por lo que obtenemos un crash.

Déjame adivinar. Si inicias un bucle en un hilo de la terminal desde la dll, se cuelga, y si lo ejecutas en un hilo separado, al que separas(), entonces la terminal se cuelga con un error?
 
Roman:

No recuperar el control es sólo un ejemplo, está claro que el while debe ejecutarse en un hilo separado para no bloquear el hilo

Así que danos un ejemplo adecuado y deja los archivos adjuntos en paz. gestiona la creación/eliminación de hilos explícitamente por ti mismo.
 

Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading

Bichos, errores, preguntas

Sergey Dzyublik, 2019.05.26 15:12

Lamentablemente, por el momento los tipos de punteros de función en MT4/MT5 son muy limitados y no son prácticos debido a algunos defectos:
#(no solucionado en MT5(build 2118))"Error de compilación al usar la misma firma de función repetidamente dentro de typedef".
#(no arreglado en MT5(build2118))"Cuando se trabaja con typedef, el uso de una función de plantilla con especialización explícita no genera código para esa función de plantilla".


En vista de la implementación esperada del espacio de nombres, por favor considere implementar el soporte para este comportamiento en el próximo C++ como parte de las correcciones de defectos:
//#include <iostream>

template<typename T>
class A{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
    T data;
};

template<typename T>
class B{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
};

template<typename T>
void func(T& value){
    ++value;
}


void OnStart(){
//int main(){
    A<int> a;
    B<int> b;
    
    a.f_ptr = func<int>;      // automatic code generation of templates functions
    b.f_ptr = a.f_ptr;        // assignment operation for function pointers with the same function signatures and different function pointer types.
    
    int x = 1;
    b.f_ptr(x);
    printf("%d\r\n", x);                  //2
    printf("%d\r\n", b.f_ptr == a.f_ptr); //1     // equal operation for function pointers with the same function signatures and different function pointer types.
}

MT5 (build 2118), ¿Cuánto tiempo más podemos esperar para que se corrijan los errores en la funcionalidaddel typedef?
Algunas tonterías - un paso a la izquierda de un ejemplo primitivo sobre el uso detypedef y eso es todo -un montón de errores que bloquean el desarrollo posterior.

 
Vladimir Simakov:
Déjame adivinar. Si se ejecuta un bucle de la dll en un hilo de la terminal, se cuelga, pero si se ejecuta en un hilo separado al que se separa(), la terminal se bloquea con un error?

No exactamente.
El lanzamiento de un bucle funciona bien.
El problema es cuando se detiene forzosamente el programa y se pasa una bandera al bucle para salir del mismo y terminar una función en ejecución.
Pero el terminal no permite salir del bucle y terminar la función en ejecución correctamente, porque la descarga anticipada de la dll ya está activada. Se nos cuelga.
La dll se descarga antes de pasar el estado de la bandera y la función Fn no termina, la descarga temprana rompe todo.

Yo lo hice en hilo de terminal por ejemplo, para evitar escribir todo el código, porque en modo de bloqueo se ve mejor el problema.
He creado una función separada para la bandera del bucle y el bucle en ejecución se ejecuta en un hilo diferente, pero el mismo comportamiento.
Y cuando intento cambiar la bandera a otro estado desde el código mql no bloqueado, a través de una función para salir del bucle,
el terminal no espera a que termine el bucle en ejecución, y no deja que la función Fn termine donde se está ejecutando el bucle.
El terminal realiza inmediatamente una descarga anticipada de dll sin esperar a que la función Fn se complete. Este es el problema.

TheXpert:
así que da un ejemplo adecuado de inmediato. y deja el attachi detachi en paz. controla la creación/eliminación de hilos explícitamente tú mismo.

Se puede ver mejor el problema en el modo bloqueado. No importa realmente lo que cambie el estado de la bandera. Con un punto de entrada o una función independiente.
El punto de entrada es mejor para el modo bloqueado, ya que el control no se devuelve y no se puede llamar a la función de cambio de bandera. Por eso se utiliza como ejemplo el atachi detechi.
Atachi detachable dejó solo, hizo una función separada como usted aconsejó, no hubo suerte, en un proyecto de trabajo en el modo de no bloqueo, el mismo comportamiento.
La dll se descarga antes de tiempo, la función que se ejecuta con el bucle while no tiene tiempo para completar y se cuelga.

 
Roman:

La dll se descarga antes de tiempo, una función en ejecución con un bucle while no tiene tiempo para terminar y se produce un cuelgue.

no puede haber un cuelgue en una aplicación normal

 

¿Alguien se ha encontrado con el siguiente problema con los símbolos personalizados? La función CustomRatesUpdate recibe las cotizaciones normales, pero en realidad el gráfico y la ventana de datos contienen algo extraño (en este caso los valores de cierre y baja son 100 veces menores que los pasados):

Además, en paralelo, los ticks individuales se emulan con CustomTicksAdd con los mismos valores de precio de cierre que en el registro (inmediatamente antes de CustomRatesUpdate), es decir, no está claro de dónde vienen los valores reducidos en las cotizaciones.

UPD:

Tengo una situación "inversa" en el USDCAD - las cotizaciones aumentan 10 veces después de escribir. Este es el registro que estoy recibiendo:

2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]  [high]   [low] [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32987 1.32987 1.32980 1.32987           457       48             0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) Retry: 1 0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]   [high]   [low]  [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32980 13.29730 1.32980 13.29730           457       52             0

El primer ArrayPrint es lo que se escribió en CustomRatesUpdate, y el segundo ArrayPrint es lo que se leyó usando CopyRates de la última barra más reciente inmediatamente después de la escritura. En primer lugar, la diferencia es el último dígito de la apertura, pero lo más importante es que el máximo y el cierre se multiplican por 10.

 
Stanislav Korotky:

¿Alguien se ha encontrado con el siguiente problema con los símbolos personalizados? La función CustomRatesUpdate recibe las cotizaciones normales, pero en realidad el gráfico y la ventana de datos contienen algo extraño (en este caso los valores de cierre y baja son 100 veces menores que los pasados):

Además, los ticks individuales se emulan en paralelo utilizando CustomTicksAdd con los mismos valores de precio de cierre que hay en el registro (inmediatamente antes de CustomRatesUpdate), es decir, no está claro de dónde vienen los valores reducidos en las cotizaciones.

Sí, me lo he encontrado, pero mi nulo no era claro. Tienes 100 veces el número de picos.
Hice una comprobación extra de cero, no sirvió de nada, funcionaba todo mal, luego sacaba esos picos.
Principalmente, este comportamiento se observó la primera vez que inicié el programa, y la primera vez que creó archivos de historial con una fecha inexistente.
Carpeta limpia garrapatas, código corregido, con el fin de encontrar donde el error, aburrido, pospuesto por ahora, pero también tienen que volver a este problema ((
Comprueba también la carpeta custom history, puede haber archivos con una fecha que no existe )))
En general, el bicho vive allí específico.

Por favor, duplique el problema en este hilo
Creo que Slava está a cargo de los personajes personalizados allí.
Para recordar el problema.
 

¿Se ha mencionado este error antes? No lo encuentro. Conclusión: cuando se cargan los resultados de optimización desde el archivo de caché, los resultados de avance se muestran incorrectamente. Los valores de los parámetros tienen dígitos erróneos.

Vas a la pestaña de optimización. Seleccione el Asesor Experto. Seleccione una de las anteriores optimizaciones. Las pruebas retrospectivas se cargan normalmente. Los delanteros dan esto:



MT5, última versión. x64.

1...253425352536253725382539254025412542254325442545254625472548...3187
Nuevo comentario