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

Новый комментарий
 

Смотрите раздел Свойства программ (#property):

tester_indicator

string

Имя пользовательского индикатора в формате "имя_индикатора.ex5". Необходимые для тестирования индикаторы определяются автоматически из вызова функций iCustom(), если соответствующий параметр задан константной строкой. Для остальных случаев (использование функции IndicatorCreate() или использование неконстантной строки в параметре, задающем имя индикатора) необходимо данное свойство

tester_file

string

Имя файла для тестера с указанием расширения, заключенное в двойные кавычки (как константная строка). Указанный файл будет передан тестеру в работу. Входные файлы для тестирования, если необходимы, должны указываться всегда

tester_library

string

Имя библиотеки с расширением, заключенное в двойные кавычки. Библиотека может быть как с расширением dll, так и с расширением ex5. Необходимые для тестирования библиотеки определяются автоматически. Однако, если какая-либо библиотека используется пользовательским индикатором, то необходимо использовать данное свойство

 
Rosh:

Смотрите раздел Свойства программ (#property):


Спасибо.
 

На тиковом графике(в обзоре рынка) на демо счете по XAUUSD происходит постояный сброс.

А еще:

Открываете "подробности" и мышкой на пустое место

 

Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
  • www.mql5.com
Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете - Документация по MQL5
 
gumgum:

На тиковом графике(в обзоре рынка) на демо счете по XAUUSD происходит постояный сброс.

А еще:

Открываете "подробности" и мышкой на пустое место

 

 

Не совсем понятно что значит постоянный сброс.

Какая ОС, какаябитность ОС и терминала? 

 
Rosh:

Учите, ибо в писании документации сказано - Технические индикаторы:

Это означает, что при первом запуске индикатора (при переключении на новый таймфрейм в первый раз), значения индикатора еще не рассчитаны, поэтому и prev_calculated=0. При возврате на этот таймфрейм индикатор не создается заново, ибо хэндл его еще живой, в результате на графике рассчитывается уже существующий индикатор по существующему хэндлу. Поэтому и prev_calculated!=0

 Вот уже готов был поймать на слове, да передумал. Полученные мною результаты внешне почти что говоят о том, что не всегда всё так гладко, есть некоторые исключения... но пока не пойму, связаны ли они, эти исключения, с хэндлами или это какой-то другой затык?

 "Примечание: если функция OnCalculate возвращает нулевое значение, то в окне DataWindow клиентского терминала значения индикатора не показываются." Спешу заверить: всё намного хуже, если я правильно сумел увязать в голове результаты с документацией и самостоятельно интерпретировать полученный эффект. Значение индикатора не только не отрисовываются - работа всего индикатора встаёт, очередь команд замирает, отработку последующих команд дождаться невозможно. Вот, собственно, о чём я успел сообщить мельком в некоторых предыдущих постах.

 Как уже упоминалось, в коде есть множество команд Copy... , не задействующих хэндл, (то есть все, кроме CopyBuffer). Они проходят проверку if'ом и в случае, если результат копирования <= 0, осуществляют тот самый return(0), после которого "значения индикатора не показываются" и вообще наступает полный паралич в работе индикатора.

 Не поленюсь напомнить, что первичная неотрисовка с сопутствующим ей всеобщим параличом наблюдается в бестиковом режиме работы терминала (то есть либо в выходные, либо в офф-лайн). Не сочтите это за несущественный момент, ибо никому не хочется отлаживать свои индикаторы по выходным, совершая лишние телодвижения, бегая по таймфреймам и инициируя искусственно - вручную - первую отрисовку. Да и не только в отладке дело...

 Если честно, мне не хватило ума увязать любезно предоставленные ссылки на примеры из документации, где говорится про увеличение счётчика ссылок на уже существующий хэндл (а также с прочими приведёнными ответами) с существующей проблемой. По-моему, ноги у неё растут совсем не оттуда.

 Попробуйте воспроизвести прикреплённый код при следующих условиях: предзаданный таймфрейм в коде - D1, текущий таймфрейм в терминале - D1, терминал в режиме офф-лайн. При набрасывании индикатора на график с указанным текущим ТФ в закладке Эксперты мгновенно появится результат логгирования.

 Теперь полностью выгрузите терминал, перезапустите, перейдите на отличный от D1 таймфрейм. Набросьте индикатор - внешне изменений не произойдёт до тех пор пока не перейдёте на любой другой (не обязательно D1) таймфрейм.

 Из-за этой неприятной особенности пропадает хорошая идея вместе с недописанным индикатором.

У разработчиков, я уверен, найдутся объяснения такому поведению в работе индикатора, но несправедливо, когда данные предзаданного в хэндле ТФ отрисовываются во всех отношениях безукоризненно, когда пользователь находится в данный момент именно на том ТФ, а если на другом, то вынужден совершать лишние телодвижения. Я - за равноправие в работе таймфреймов при использовании хэндлов внешних индикаторов, остальные ТФ ведь ни в чём не провинились.

 P.S.: так... Стоп. Сейчас ещё раз проверил - оказывается, CopyHigh здесь даже не влияет на этот паралич. Теперь я вообще ничего не понимаю. Все подозрения резко пали на хэндл, что в OnInit...

 P.P.S.: добавил второй пример кода - даже он не откликается. 

Файлы:
paralich.mq5  3 kb
paralich2.mq5  2 kb
 

 Найдена граница проблемы.

 Закомментируйте:

   SetIndexBuffer(0,FractalUpBuffer,INDICATOR_DATA);
   PlotIndexSetInteger(0,PLOT_ARROW,217);
   PlotIndexSetInteger(0,PLOT_ARROW_SHIFT,ArrowShift);

- и проблема исчезнет, но тогда это будет явное указание на эпизодическую некорректность связывания буферов через SetIndexBuffer. А это уже указывает на необходимость отказаться от использования SetIndexBuffer и прибегнуть к ручному манипулированию размером контролируемого буфера.

 Помимо этого, прикреплённый пример явно демонстрирует неспособность BarsCalculated(handle) вовремя обсчитать значения вызванного индикатора на любом текущем ТФ, если только он не совпадает с предзаданным, или принципиальную неготовность что-либо обсчитывать на них в первый раз (скорее всего этот вариант). При этом значение будет <=0, return(0) и стопор как результат.

Файлы:
boundary_of_the_problem.mq5  2 kb
 
alexvd:

Не совсем понятно что значит постоянный сброс.

Какая ОС, какаябитность ОС и терминала? 

W7 и MT5 64 bit. 

пример:

 

 

XAUUSD постояно сбрасывается в начало.(XAGUSD привел для сравнения)  

 
x100intraday:

 Найдета граница проблемы.

 Закомментируйте:

- и проблема исчезнет, но тогда это будет явное указание на эпизодическую некорректность связывания буферов через SetIndexBuffer. А это уже указывает на необходимость отказаться от использования SetIndexBuffer и прибегнуть к ручному манипулированию размером контролируемого буфера.

 Помимо этого, прикреплённый пример явно демонстрирует неспособность BarsCalculated(handle) вовремя обсчитать значения вызванного индикатора на любом текущем ТФ, если только он не совпадает с предзаданным. При этом значение будет <=0, return(0) и стопор как результат.

 

По первому примеру (второй не смотрел), в индикаторе paralich есть функция 

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
bool FillArraysFromBuffers(double &up_arrows[],datetime &up_times[],int ind_handle,int amount)
  {
   if(CopyBuffer(ind_handle,0,0,amount,up_arrows)<0) return(false);
   else CopyTime(_Symbol,PERIOD_D1,0,amount,up_times);

   return(true);
  }

Так вот представьте, что ваш индикатор находится на D1, и вы пытаетесь в его индикаторный буфер скопировать данные с таймфрейма H1. Количество элементов не совпадет. Думаю, что ваша проблема кроется именно здесь - нет проверки перед копированием данных.

Примеры индикаторов, которые берут данные с других таймфреймов, есть в справке для каждого технического индикатора. Например, https://www.mql5.com/ru/docs/indicators/iama:

//--- узнаем количество рассчитанных значений в индикаторе
   int calculated=BarsCalculated(handle);
   if(calculated<=0)
     {
      PrintFormat("BarsCalculated() вернул %d, код ошибки %d",calculated,GetLastError());
      return(0);
     }
//--- если это первый запуск вычислений нашего индикатора или изменилось количество значений в индикаторе iAMA
//--- или если необходимо рассчитать индикатор для двух или более баров (значит что-то изменилось в истории)
   if(prev_calculated==0 || calculated!=bars_calculated || rates_total>prev_calculated+1)
     {
      //--- если массив iAMABuffer больше, чем значений в индикаторе iAMA на паре symbol/period, то копируем не все 
      //--- в противном случае копировать будем меньше, чем размер индикаторных буферов
      if(calculated>rates_total) values_to_copy=rates_total;
      else                       values_to_copy=calculated;
     }
   else
     {
      //--- значит наш индикатор рассчитывается не в первый раз и с момента последнего вызова OnCalculate())
      //--- для расчета добавилось не более одного бара
      values_to_copy=(rates_total-prev_calculated)+1;
     }
Документация по MQL5: Технические индикаторы / iAMA
Документация по MQL5: Технические индикаторы / iAMA
  • www.mql5.com
Технические индикаторы / iAMA - Документация по MQL5
 
x100intraday:

 Попробуйте воспроизвести прикреплённый код при следующих условиях: предзаданный таймфрейм в коде - D1, текущий таймфрейм в терминале - D1, терминал в режиме офф-лайн. При набрасывании индикатора на график с указанным текущим ТФ в закладке Эксперты мгновенно появится результат логгирования.

И вообще, пробовали вместо логирования использовать отладку, чтобы не поулчать тонны сообщений? Справка по MetaEditor → Разработка программ → Отладка 
 
Rosh:

Так вот представьте, что ваш индикатор находится на D1, и вы пытаетесь в его индикаторный буфер скопировать данные с таймфрейма H1. Количество элементов не совпадет. Думаю, что ваша проблема кроется именно здесь - нет проверки перед копированием данных. 

 Первым делом собираюсь уточнить: разве случаи переполнения массива при копировании значений через Copy...-функции не вызывают сообщение об ошибке переполнения "Array out of range" в Экспертах клиентского терминала? Помню, что после успешной компиляции, уже во время работы индикатора, такое сообщение иногда генерируется, но точно не скажу, на что именно. По-моему, это и не на Copy...-функции вовсе, а на обращение по несуществующему индексу, что ли...

 Во-вторых, спешу заверить, что Ваша гипотеза об отсутствии проверки не совсем верна. Речь может идти разве что о некорректно составленном if-else-фильтре, но никак не о полном его отсутствии. Уж на нём-то я не один десяток раз споткнулся. Недавно задавал то ли здесь, то ли в "Чайниках" вопрос про аналог rates_total для таймфреймов, отличных от текущего, но ответа ни от кого не получил. Дело в том, что rates_total - это один из параметров текущего таймфрейма, а для меня он совершенно бесполезен, так как я работаю с массой других ТФ, а если так или иначе оказываюсь иногда на одном из предзаданных, то всё равно использую для расчётов вместо rates_total ТФ-универсальную calculated=BarsCalculated(handle). Возможно, я совершаю большую ошибку, но для этой задачи пользы в rates_total я не вижу.

 В-третьих, я давно смог добиться того, чтобы, находясь на старшем ТФ, успешно копировать и перераспределять значения младших ТФ, и наоборот. Те примеры, что я давал несколько дней тому назад - минимальны, но исчерпывающи, там это всё есть. Несовпадение количества элементов от двух разных ТФ бывают двух видов: недостаток и избыток. Первый вариант нестрашен, а вот второй я ещё попроверяю на предмет переполнения и попробую ограничить, если что не так. По логике: индикатор впадал бы в ступор из-за недостающей проверки Copy-функции только при переполнении, но в ступор-то он встаёт так же и в случае, когда копируемых с другого ТФ баров меньше, чем количество баров на текущем.

 В-четвёртых же, индикатор уже с неделю как испечён и выверен, никаких явных ошибок не выдаёт (ни при компиляции, ни в процессе работы), остались лишь неявные проблемы, одна из которых - первичная неотрисовка на определённых ТФ, а также резкое увеличение расчётного времени на M1 при повторном переключении на него (в первый раз всё обсчитывается в пределах 2-3 секунд). Индикатор словно захлёбывается в расчётах (лавинообразная утечка памяти?) Сделал ограничение на число копируемых элементов посредством CopyBuffer - до 200 вместо всей истории, но это не изменило ситуацию. Было замечено, что в офф-лайн на M1 и везде обсчёт всегда быстрый, как в первый раз, в он-лайн ситуация резко меняется (видимо, проблема в том самом условном фильтре, что-то пропускающем на каждом тике, хотя этого быть не должно, так как частота перерисовки зависит от дорисовки нового - нулевого - бара и не может быть чаще самого младшего предзаданного ТФ в одном из хэндлов). Из мелких, но неприятных проблем: малейшая попытка скроллинга чарта колёсиком мыши дематериализует все фракталы и приходится ждать, пока они вновь рассчитаются и отрисуются (хотя новых баров не поступало, перерасчитывать вроде бы нечего).

1...563564565566567568569570571572573574575576577...3518
Новый комментарий
Причина обращения: