Errores, fallos, preguntas - página 2179

[Artyom Trishkin]

Nikolai Semko:

No, no tiene nada que ver con la carga.

Si no se toma una barra de inicio cero, sino digamos 50 barras, entonces todo está bien. Instantáneo.

Y si lo llevo hasta los 30 bares inclusive, se congela. Después, no lo hace.

¡DEFINITIVAMENTE ES UN ERROR!

Prueba con este:

//+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| https://www.mql5.com/ru/code/1864                                |
//+------------------------------------------------------------------+
int iBarShift(const string symbol_name,const ENUM_TIMEFRAMES timeframe,const datetime time,bool exact=false)
  {
   datetime last_bar;
   if(!SeriesInfoInteger(symbol_name,timeframe,SERIES_LASTBAR_DATE,last_bar))
     {
      datetime array[1];
      if(CopyTime(symbol_name,timeframe,0,1,array)==1)
         last_bar=array[0];
      else
         return WRONG_VALUE;
     }
   if(time>last_bar)
      return(0);
   int shift=Bars(symbol_name,timeframe,time,last_bar);
   datetime array[1];
   if(CopyTime(symbol_name,timeframe,time,1,array)==1)
      return(array[0]==time ? shift-1 : exact && time>array[0]+PeriodSeconds(timeframe) ? WRONG_VALUE : shift);
   return WRONG_VALUE;
  }
//+------------------------------------------------------------------+

[Nikolai Semko]

Artyom Trishkin:

Prueba con este:

¿Qué tiene que ver iBarShift con todo esto?

Se trata de un error en la función estándar de Bares

[Artyom Trishkin]

Nikolai Semko:

¿Qué tiene que ver iBarShift con todo esto?

Se trata de un error en la función estándar de Bares

Esta función también utiliza Bars(). Has empezado con el análogo de iBarShift()

[Nikolai Semko]

Artyom Trishkin:

Esta función también utiliza Bars(). En su caso, todo comenzó con el análogo de iBarShift()

Sí, por supuesto, el uso de la contraparte de iBarShift reveló este problema.

Si se utiliza la función iBarShift dada por usted, no se detectará este error, porque sólo se utiliza un TF allí,

Y este error se produce cuando se utilizan diferentes TF en las funciones CopyTime y Bars.

Pero Bares debería funcionar normalmente para cualquier momento. Pero mi ejemplo muestra que hay un caso especial, donde iBar se cuelga durante decenas de segundos. Y no tiene nada que ver con cargar la historia.

[Vitaly Muzichenko]

Nikolai Semko:

Sí, por supuesto, el uso de la contraparte de iBarShift reveló este problema.

Si se utiliza la función iBarShift dada por usted, no se detectará este error, porque sólo se utiliza un TF allí,

Y este error ocurre cuando se utilizan diferentes TF en las funciones CopyTime y Bars.

Pero Bares debería funcionar normalmente para cualquier momento. Pero mi ejemplo muestra que hay un caso especial, donde iBar se cuelga durante decenas de segundos. Y no tiene nada que ver con cargar la historia.

Lo más probable es que esto se deba a la carga de la historia

[Kirill Belousov]

Nikolai Semko:

Sí, por supuesto, el uso de la contraparte de iBarShift reveló este problema.

Si se utiliza la función iBarShift dada por usted, no se detectará este error, porque sólo se utiliza un TF allí,

Y este error ocurre cuando se utilizan diferentes TF en las funciones CopyTime y Bars.

Pero Bares debería funcionar normalmente para cualquier momento. Pero mi ejemplo muestra que hay un caso especial, donde iBar se cuelga durante decenas de segundos. Y no tiene nada que ver con cargar la historia.

Creo que hay un intento de sincronización cíclica en una situación en la que no hay barras en el rango solicitado - Bares se esfuerza por "trabajar normalmente" y luego se rinde por un tiempo de espera o número de intentos de sincronización.

Debería comprobar los valores usted mismo para evitar llamar a Bars en tal caso.

[Nikolai Semko]

Vitaly Muzichenko:

Lo más probable es que esto se deba a la carga del historial

No estoy de acuerdo. No se habría descargado de nuevo durante 22 segundos. Además, tengo todo el historial de todos los TFs cargados por un indicador especial.

Si fuera una carga, entonces cómo se explica que los primeros 31 compases necesiten carga y los siguientes no.

[A100]

Nikolai Semko:

Si fuera una subcarga, entonces cómo se explica que los primeros 31 compases necesiten una subcarga y los siguientes no.

De la documentación: Cuando se solicita el número de barras en un rango de fechas determinado, sólo se tienen en cuenta las barras cuya hora de apertura se encuentra dentro de este rango.

En consecuencia, el prototipo Bars() devuelve cero, lo que se interpreta como que no hay historia y ::Bars() en el caso del script, como se señaló correctamente en un post anterior, termina por tiempo de espera o por el número de intentos fallidos.

[Nikolai Semko]

Kirill Belousov:

Creo que hay un intento de sincronización cíclica cuando no hay barras en el rango solicitado - Bares se esfuerza por "trabajar normalmente" y luego se rinde por el tiempo de espera o el número de intentos de sincronización

La razón de estos casos es que no debe llamar a Bars para comprobar los valores por sí mismo.

Es muy posible.
Pero hay muchas opciones.

Las barras son una función muy importante, y es difícil prescindir de ellas. Para ser exactos, puedes prescindir de él, pero te costará muchos recursos.

Debes asegurarte de que funciona perfectamente.

[Nikolai Semko]

A100:

De la documentación: Al solicitar el número de bares en un rango de fechas determinado, sólo se tienen en cuenta los bares cuyos horarios de apertura se encuentran dentro de este rango .

En consecuencia, el prototipo Bars() devuelve cero, lo que se interpreta como una falta de historia y el script, como se señaló correctamente en un mensaje anterior, termina por tiempo de espera o número de intentos fallidos.

Está claro que es cero.

¿Y qué? ¿Está bien que se tarden 22 segundos en decidir que hay cero barras en un rango de tiempo determinado?

Hay un error algorítmico evidente en la implementación interna de Bares.

Deberíamos enviar una solicitud al Service Desk sobre este tema - el fin de semana está por delante y el tema podría perderse el lunes.