Ошибки, баги, вопросы - страница 2179

 
Nikolai Semko:

Нет, подгрузка здесь ни при чем.

Если брать не нулевой стартовый бар, а скажем 50 бар, тогда все ОК. Мгновенно.

Причем если беру по 30 бар включительно - зависает. А после нет.

СТОПУДОВЫЙ БАГ!

Попробуйте вот этот:

//+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| 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;
  }
//+------------------------------------------------------------------+
 
Artyom Trishkin:

Попробуйте вот этот:

Да причем тут iBarShift?

Сейчас речь о баге стандартной функции Bars 

 
Nikolai Semko:

Да причем тут iBarShift?

Сейчас речь о баге стандартной функции Bars 

В той функции тоже Bars() используется. У вас же всё началось как раз с аналога iBarShift()

 
Artyom Trishkin:

В той функции тоже Bars() используется. У вас же всё началось как раз с аналога iBarShift()

Да, конечно, юзание аналога iBarShift выявило эту проблему.

Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,

А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.

Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем. 

 
Nikolai Semko:

Да, конечно, юзание аналога iBarShift выявило эту проблему.

Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,

А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.

Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем. 

Скорее всего это и связано с подгрузкой истории

 
Nikolai Semko:

Да, конечно, юзание аналога iBarShift выявило эту проблему.

Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,

А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.

Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем. 

Думаю, что идет попытка цикличной синхронизации в ситуации отсутствия баров в запрошенном диапазоне - Bars во всю старается "нормально отрабатывать" и потом сдается по таймауту или кол-ву попыток синхронизации

Надо самому делать проверки значений , чтобы не вызывать Bars для такого случая.

 
Vitaly Muzichenko:

Скорее всего это и связано с подгрузкой истории

Не согласен. Она бы повторно бы тогда не закачивалась снова 22 секунды. Тем более у меня вся история по всем TФ загружена специальным индикатором.

Если бы это была подгрузка, тогда как объяснить, что первым  31 барам нужна подгрузка, а последующим не нужна. 

 
Nikolai Semko:

Если бы это была подгрузка, тогда как объяснить, что первым  31 барам нужна подгрузка, а последующим не нужна.

Из документации: При запросе количества баров в заданном диапазоне дат учитываются только те бары, чье время открытия попадает в этот диапазон.

Соответственно прообраз Bars() возвращает ноль, который интерпретируется как отсутствие истории и ::Bars() в случае скрипта как было верно замечено в предыдущем сообщении завершается по таймауту или числу неудачных попыток.

 
Kirill Belousov:

Думаю, что идет попытка цикличной синхронизации в ситуации отсутствия баров в запрошенном диапазоне - Bars во всю старается "нормально отрабатывать" и потом сдается по таймауту или кол-ву попыток синхронизации

Надо самому делать проверки значений , чтобы не вызывать Bars для такого случая.

Вполне возможно. 
Но вариантов масса. 

Bars очень важная функция, без нее сложно обойтись. Точнее можно обойтись, но ценой повышенной траты ресурсов.

Необходимо безупречное ее функционирование.

 
A100:

Из документации: При запросе количества баров в заданном диапазоне дат учитываются только те бары, чье время открытия попадает в этот диапазон .

Соответственно прообраз Bars() возвращает ноль, который интерпретируется как отсутствие истории и скрипт как было верно замечено в предыдущем сообщении завершается по таймауту или числу неудачных попыток.

Понятно, что ноль. 

И что - это нормально 22 секунды на решение что ноль баров в заданном временном промежутке?

Явный же алгоритмический баг внутренней реализации Bars.

Пожалуй надо оформить заявку в сервисдеск по этому вопросу, а то впереди выходные и эта тема может просто затеряться до понедельника.

Причина обращения: