[SERVICE DESK] ¡Error al obtener la hora de la TF superior en el temporizador! - página 2
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
Una vez más. No lo dice en ningún sitio. Eso es lo primero. En segundo lugar, ¿por qué entonces es engañoso al mostrar primero un código de error 4066 y luego no?
Los datos se bombean por lotes y luego son procesados por el terminal, y como estás trabajando en un temporizador, estás en pausa. No lo veo explícitamente en ningún sitio, pero muchos programadores que escriben aplicaciones MTF suelen conocerlo y te lo he contado enseguida.
https://docs.mql4.com/ru/series/timeseries_access lo leyó detenidamente.
Bueno, arriba ya nos dio una variante de comprobar la accesibilidad del historial. No es perfecto, pero es sencillo y evidente.
Si esta variante no funciona, compruebe lo siguiente.
Los datos se bombean en porciones y luego son procesados por el terminal, y como estás en un temporizador, te pones en pausa. Sí, no se menciona explícitamente en ningún sitio, pero muchos programadores que escriben aplicaciones MTF suelen conocerlo y se lo dije enseguida.
https://docs.mql4.com/ru/series/timeseries_access lo leyó detenidamente.
Bueno, arriba ya nos has dado una variante de comprobar la accesibilidad del historial. No es perfecto, pero es sencillo y evidente.
Sobre lo de "entrar en pausa", ¿dónde están las pruebas?
Lo he leído con atención (y lo he leído antes). Soy consciente de que los datos (especialmente los TF más antiguos) no siempre están disponibles de forma inmediata. No hay problema. ¿Pero por qué entonces la función SeriesInfoInteger() no devuelve ningún error? ¡Aquí está la pregunta!
Suponiendo que la solicitud cae en alguna pausa/intercambio/actualización/interrupción, etc., entonces que devuelva el código de error != 0. Y no habrá ningún problema.
Y arriba ya has dado la opción de comprobar la accesibilidad de la historia. No es perfecto, pero es simple y sencillo.
Respondido arriba @Ihor Herasko sobre este punto.
Ya he respondido a @Ihor Herasko sobre este punto.
He dado mi versión de la prueba anterior. Por qué tanta pregunta a los desarrolladores, pero este punto se conoce desde hace mucho tiempo.
Sin duda, probaré su versión de la prueba e informaré de los resultados.
Sin duda, probaré su versión de la prueba e informaré de los resultados.
Primero una respuesta de @Ihor Herasko. Código para la reproducción:
Resultado:
Según las entradas del registro. La terminal se apagó a las 14:25. A continuación, se encendió a las 14:30. Comprobamos la hora del bar M15. Empezamos con la TF M1. El indicador (código anterior) mostraba la hora real de apertura 12:15 (hora de la terminal, retrasada respecto a mi hora local en 2 horas). ¡El resultado debería haber sido 12:30! Conclusión: el error está presente. Y este método sugerido por @Ihor Herasko no funciona.
Asegúrese de informar al respecto. A mí me funciona. Pero puede haber todo tipo de trampas si no funciona, pensemos qué más podemos hacer.
Me despido. Código:
Resultado:
Apagó el terminal a las 14:48 y lo volvió a encender a las 15:01. Debería haber recibido la hora a la 1:00 p.m. Tengo las 12:45. ¿Alguna otra pregunta?
Cambié el TF de M1 a M5 y obtuve un resultado correcto:
¡Creo que lo tengo! ¿Se pone en marcha el indicador inmediatamente con el terminal? ¡Si es así, antes de comprobar esperar una conexión con el servidor IsConnected() tiene un temporizador muy rápido no tiene tiempo para sincronizar!
O haz esto
Pero hay que tener en cuenta la diferencia entre la hora del servidor y la hora local. Escriba de nuevo con los resultados.