Archivo de la versión MT. - página 4
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
En este contexto, ¿no podemos hacer la comprobación?
Desgraciadamente, esta comprobación no ha aportado nada...
Al dar un ejemplo con IsStopped(), sólo intentaba responder a la primera parte.
A veces es necesario completar la tramitación de un evento con antelación, y a veces es urgente como en su caso.
Lea la descripción de esta función IsStopped() en la documentación, tal vez le dé algunas ideas.
Pero a ti te parece que es desde otra dirección. Si es así, perdón por una posible suposición.
Pero como dicen en posibles sugerencias, y resuelve el problema.
La solución definitiva no se la dirá a nadie, porque nadie conoce toda la lógica de su código, y probablemente no profundizará en ella.
Roman, una vez más, no estás citando hasta el final. Y tú lo has destacado entre todos los destacados.
Bien, digamos que se inicia un cierre forzado. Lo que necesito es que el evento en el que se dispara esta terminación se ejecute hasta el final y la complejidad de los cálculos supere los 3 segundos. ¿Y cómo puedo evitar la terminación del programa y dejar que se ejecute hasta el final? Ese es exactamente el problema. La conversación no versaba sobre cómo terminar, sino sobre cómo evitar una terminación incorrectamente invocada. O no impedir, sino aplazar hasta un momento determinado, en particular hasta que se complete el procesamiento del evento.
Aquí tienes una comprobación de tu opción. Terminó con un mensaje como este:
Es un callejón sin salida...
Así que la opción sugerida es
se elaborará exactamente de la misma manera. Y volverás a tener un "punto muerto". Pero el bloqueo no está en mql, sino en tu mente. Esta no es forma de programar. Antes de esperar nada del código, imagínate en el lugar de un idiota y recorre a ciegas, como un ordenador, todo el código varias veces. Asegúrese de dónde debe pasar la ejecución en un caso particular. Qué parámetros deben recibirse en un caso concreto. A continuación, iniciamos la ejecución y comprobamos si obtenemos lo que esperamos. Si no, entonces debemos averiguar de dónde sacamos lo que vemos durante el proceso de depuración.
No puede ser de otra manera. Y es absolutamente imposible depurar los fragmentos de código.
Roman, una vez más, no estás citando hasta el final. Y tú has destacado entre todos los destacados.
Bueno, vale, digamos que se activa una terminación forzada. Y necesito que el evento en el que se dispara esta terminación se ejecute hasta el final y la complejidad de los cálculos supere los 3 segundos. ¿Y cómo puedo evitar la terminación del programa y dejar que se ejecute hasta el final? Ese es exactamente el problema. La conversación no versaba sobre cómo terminar, sino sobre cómo evitar una terminación incorrectamente invocada. O no para impedir, sino para retrasar hasta un determinado momento, en particular hasta que se complete el procesamiento del evento.
Hay que esperar a que se complete el cálculo.
Desafortunadamente, mql no contiene funciones como await.
Podemos intentar experimentar con Sleep(), pero el deslizamiento no es una señal explícita de terminación, por lo que no es muy adecuado.
Intente crear otra condición, si (el cálculo se ejecuta), entonces ya iniciaremos una terminación forzada.
Así que la opción que propongo
se elaborará exactamente de la misma manera. Y una vez más obtendrá un "punto muerto". Pero el bloqueo no está en mql, sino en tu mente. No se puede entrar a programar así. Antes de esperar nada del código, imagínate en el lugar de un idiota y recorre a ciegas, como un ordenador, todo el código varias veces. Asegúrese de dónde debe pasar la ejecución en un caso particular. Qué parámetros deben recibirse en un caso concreto. A continuación, iniciamos la ejecución y comprobamos si obtenemos lo que esperamos. Si no, entonces debemos averiguar de dónde sacamos lo que vemos durante el proceso de depuración.
No puede ser de otra manera. Pero no se puede depurar el código fragmento a fragmento.
Bueno, esa es la cuestión es que todo funcionaba antes de la actualización y ahora no sé qué hacer.
Además, todo el código está abierto en principio.
Además, quería abrir un hilo para discutir la mejora de mi versión OnTester() y aquí está...
Resultó que el problema no está en él, sino en la ejecución modificada de TesterStop(). En realidad no tiene ninguna relación directa con OnTester(), pero me ha estropeado el ánimo...
Intentaré otra cosa ahora...
Esa es la cuestión, antes de la actualización todo funcionaba, pero ahora no sé qué hacer.
Además, en principio, todo el código es abierto.
Además, ya quise abrir un hilo discutiendo la mejora de mi versión OnTester() y aquí está...
Resultó que el problema no está en él, sino en la ejecución modificada de TesterStop(). En realidad no tiene ninguna relación directa con OnTester(), pero me ha estropeado el ánimo...
Intentaré otra cosa ahora...
Has dado un enlace a las construcciones anteriores. Reemplace los archivos y compruébelos. Entonces puedes decir a todo el mundo qué compilación funciona ahora. Si no funciona, significa que los parámetros que no llevaban a esta parte del código donde ahora aparecen los problemas eran simplemente los mismos.
Así que le dio un enlace a las construcciones anteriores. Reemplaza los archivos y comprueba. Entonces puedes decir a todo el mundo qué construcción funciona ahora. Si no funciona, significa que los parámetros que no conducen a esta parte del código, donde los problemas aparecieron ahora, eran simplemente los mismos.
Así es como lo probé. Poner la construcción de 2007 y allí todos estos problemas han desaparecido. He mirado específicamente todo el registro después de la optimización. He encontrado 4 (¡sólo 4!) errores de división por cero. Esos fueron los que se produjeron cuando no hubo intercambios. Por supuesto, había que arreglar esto, pero no tuvo ningún efecto en el resultado global de la optimización. Pero la nueva construcción ha provocado una cantidad alarmante de errores y ha hecho imposible la optimización.
Ahora, con respecto al consejo de @Roman.
Gracias, fue una buena. Pero en mi caso, parecía ser inútil para TesterStop() porque TesterStop() requiere que la prueba ya haya pasado algún porcentaje desconocido. Y no hay ni una palabra al respecto en la documentación.
Pero ha funcionado bien con ExsprtRemove(). Para esta función no importa cuántas pruebas se hayan pasado allí. Pero tuvimos que envolver todo el código de trabajo en el if
Bueno, he conseguido arreglar el código con muletas. Gracias de nuevo.
P.D. En realidad tuve que hacer una muleta para otra muleta. Divertido ))))
P.D. En realidad tuvo que hacer una muleta para la otra muleta. Es gracioso ))))
No creo que no haya opciones. Si te gusta programar muletas a muletas, no tengo derecho a impedirlo. Slava respondió sobre este tema.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias
Bichos, errores, preguntas
Slava, 2019.06.16 14:04
Detener el Asesor Experto inmediatamente significa que se ha corrompido la memoria. Después de una parada inmediata del Asesor Experto, puede haber bloques de memoria sin liberar. Por lo tanto, la parada inmediata del Asesor Experto sólo se utiliza cuando el terminal del cliente o el agente probador se termina y sólo si el Asesor Experto no procesa la bandera de parada y continúa la ejecución.
TesterStop da la orden de terminar la prueba. Significa que después de que el manejador actual OnInit, OnTick, OnTimer, OnChartEvent haya terminado, no se manejarán más eventos del probador, ya que el ciclo de procesamiento ha terminado. En su lugar se llamará a OnTester y OnDeinit.
Así es como lo probé. Poner la construcción de 2007 y allí todos estos problemas han desaparecido. He mirado específicamente todo el registro después de la optimización. He encontrado 4 (¡sólo 4!) errores de división por cero. Esos fueron los que se produjeron cuando no hubo intercambios. Por supuesto, había que arreglar esto, pero no tuvo ningún efecto en el resultado global de la optimización. Pero la nueva construcción ha provocado una cantidad alarmante de errores y ha hecho imposible la optimización.
Ahora, con respecto al consejo de @Roman.
Gracias, fue una buena. Pero en mi caso, parecía ser inútil para TesterStop() porque TesterStop() requiere que la prueba ya haya pasado algún porcentaje desconocido. Y no hay ni una palabra al respecto en la documentación.
Pero ha funcionado bien con ExsprtRemove(). Para esta función no importa cuántas pruebas se hayan pasado allí. Pero tuvimos que envolver todo el código de trabajo en el if
Bueno, he conseguido arreglar el código con muletas. Gracias de nuevo.
P.D. En realidad tuve que hacer una muleta para otra muleta. Divertido ))))
Esto no es una muleta, sino una práctica recomendada por los desarrolladores.
Encontré esta función en la descripción del bucle while
Por eso se me ocurrió una idea: si esta función compruebael hecho de la terminación forzada del programa, por qué no utilizarla para TesterStop().
Es una pena que no funcione para TesterStop(), ahora lo sabremos.
Pero es justo preguntar a los desarrolladores si la funciónIsStopped() debe funcionar para la función TesterStop()?
¿Tal vez sea un error?
Pero lo principal es la solución del problema.
No creo que no haya opciones. Si te gusta programar muletas a las muletas, no tengo derecho a interferir. Slava respondió sobre este tema
Lo entiendo todo y no necesito muletas. Y tuve que buscar una muleta aquí, léase para qué.
Tal vez. Pero no recuerdo que alguien se haya quejado de ello.