Errors, bugs, questions - page 570

[Rashid Umarov]

See Programme Properties (#property):

tester_indicator	string	Имя пользовательского индикатора в формате "имя_индикатора.ex5". Необходимые для тестирования индикаторы определяются автоматически из вызова функций iCustom(), если соответствующий параметр задан константной строкой. Для остальных случаев (использование функции IndicatorCreate() или использование неконстантной строки в параметре, задающем имя индикатора) необходимо данное свойство
tester_file	string	Имя файла для тестера с указанием расширения, заключенное в двойные кавычки (как константная строка). Указанный файл будет передан тестеру в работу. Входные файлы для тестирования, если необходимы, должны указываться всегда
tester_library	string	Имя библиотеки с расширением, заключенное в двойные кавычки. Библиотека может быть как с расширением dll, так и с расширением ex5. Необходимые для тестирования библиотеки определяются автоматически. Однако, если какая-либо библиотека используется пользовательским индикатором, то необходимо использовать данное свойство

[Konstantin Chernov]

Rosh:

See Programme Properties (#property):

Thank you.

[gumgum]

On the tick chart (in the market overview) on the XAUUSD demo account there is a constant reset.

Also:

Open "details" and mouse over the empty space

[Alexey Da]

gumgum:

On the tick chart (in the market overview) on the XAUUSD demo account there is a constant reset.

Also:

Open "details" and mouse over the empty space

I'm not quite sure what a permanent reset means.

What OS, what OS and terminal capacity?

[x572intraday]

Rosh:

Learn, for it says in the writing of the documentation - Technical Indicators:

It means that at the first start of the indicator (when switching to a new timeframe for the first time), indicator values have not been calculated yet, therefore prev_calculated=0. When you return to this timeframe, the indicator is not created again, since its handle is still alive. Therefore, prev_calculated!=0

I was about to take you up on your word, but I changed my mind. The results I got outwardly almost say that everything is not always so smooth, there are some exceptions... but I still don't understand if they, these exceptions, are related to handles or is it some other hitch?

"Note: if the OnCalculate function returns a null value, the indicator values are not shown in the DataWindow of the client terminal. " I hasten to assure you: it's much worse, if I've managed to correctly relate the results in my head to the documentation and interpret the resulting effect myself. Not only indicator values are not displayed - the whole indicator stops working, the command queue freezes and you can't wait for the next commands to be processed. In fact, this is what I've managed to glimpse in some of my previous posts.

As already mentioned, the code has a lot of Copy... ...that doesn't involve a handle, (i.e. everything except CopyBuffer). If the result of copying <= 0, we get the return(0), after which"the indicator stopped working" and the indicator gets a full paralysis.

I want to remind you that the initial non-drawing with the attendant paralysis occurs in the terminal windowless mode (i.e., either at weekends or off-line). Don't consider it unimportant, because nobody wants to debug their indicators on weekends, making unnecessary gestures, running through timeframes and artificially - manually - initiating the first drawing. And it's not just about debugging.

Honestly, I didn't have enough mind to link the kindly provided links to examples from documentation, where it says about increasing reference counter to already existing handle (as well as with other answers given) to the existing problem. I don't think it's growing from there at all.

Try to reproduce the attached code under the following conditions: preset timeframe in the code is D1, current timeframe in the terminal is D1, the terminal is in offline mode. When the indicator is attached to the chart with the specified current timeframe, the results of logging will instantly appear in the Experts tab.

Now completely unload the terminal, restart it and switch to a timeframe other than D1 . Put the indicator - it will not change until you switch to any other (not necessarily D1) timeframe.

Because of this unpleasant feature a good idea disappears along with the underwritten indicator.

The developers, I'm sure, can find explanations for this behavior of the indicator, but it's unfair, when the data of TF master-defined in its handle is perfectly displayed, when a user is at that timeframe, but if he is at another one, he has to make unnecessary movements. I am for the equality of timeframes when using handles of external indicators, the other TFs are not guilty of anything.

P.S.: So... Wait. I checked it once again - it turns out that CopyHigh does not even influence this paralysis. Now I don't understand anything at all. All my suspicions suddenly fell upon a handle in OnInit...

P.P.S.: added second code example - even it doesn't respond.

[x572intraday]

The boundary of the problem has been found.

Comment it out:

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

- and the problem goes away, but then it is a clear indication of occasional incorrect buffer binding via SetIndexBuffer . And that already points to the need to abandon the use ofSetIndexBuffer and resort to manually manipulating the size of the buffer being monitored.

Besides, the attached example obviously demonstrates the inability of BarsCalculated(handle )to calculate in time the values of the called indicator on any current TF, unless it coincides with a preset one, or the unwillingness in principle to calculate anything at the first time (most probably this variant). In this case the value will be <=0, return(0) and stop as a result.

[gumgum]

alexvd:

It is not quite clear what permanent reset means.

What OS, what OS and terminal bit?

W7 and MT5 64 bit.

example:

XAUUSD always resets to the beginning (XAGUSD is a comparison)

[Rashid Umarov]

x100intraday:

Find the boundary of the problem.

Comment it out:

- and the problem will disappear, but then it will be a clear indication of occasional incorrect buffer binding via SetIndexBuffer . And that already points to the need to abandon the use ofSetIndexBuffer and resort to manually manipulating the size of the buffer being monitored.

Besides, the attached example obviously demonstrates the inability of BarsCalculated(handle) to calculate in time the value of the called indicator on any current TF, unless it coincides with a preset one. In this case the value will be <=0, return(0) and stop as a result.

For the first example (didn't look at the second one), the paralich indicator has a function

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
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);
  }

So, imagine that your indicator is on D1 and you try to copy data from H1 timeframe to its indicator buffer. The number of elements will not match. I think this is where your problem lies - there is no check before copying the data.

Examples of indicators that take data from other timeframes are available in the help for each technical indicator. For example 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;
     }

[Rashid Umarov]

x100intraday:

Try to reproduce the attached code under the following conditions: preset timeframe in the code is D1, current timeframe in the terminal is D1, terminal is in off-line mode. When an indicator is attached to a chart with the specified current timeframe, the results of logging will instantly appear in the Experts tab.

And in general, have you tried using debugging instead of logging, in order not to get tons of messages? Help in MetaEditor → Program Development → Debugging

[x572intraday]

Rosh:

So imagine that your indicator is on D1 and you are trying to copy data from H1 timeframe into its indicator buffer. The number of elements will not match. I think this is where your problem lies - there is no check before copying the data.

First of all I'm going to clarify: aren't the cases of array overflow when copying values via Copy...-functions causing an overflow error"Array out of range" in Experts of the client terminal? I remember that such messages are sometimes generated after a successful compilation, while the indicator is working, but I can't say exactly. I think it is not on Copy...-function, but on a reference to a non-existent index or something like that.

Second, I hasten to assure you that your hypothesis about absence of check is not quite correct. It may speak only about incorrectly generated if-else-filter but not about its complete absence. I have stumbled over it more than a dozen times. Recently I have asked here or in "Dummies" a question about analogue of rates_total for timeframes, different from the current one, but I haven't received an answer from anybody. The matter is that rates_total is one of parameters for the current timeframe, and it is absolutely useless for me, because I work with a lot of other timeframes, and if I happen to use one of preset ones, I still use universal calculated=BarsCalculated(handle) for calculations instead of rates_total. Perhaps I'm making a big mistake, but I don't see the usefulness of rates_total for this task.

Thirdly, I have long been able to achieve that, being in a high TF, I can successfully copy and redistribute values of lower TFs, and vice versa. Those examples I gave a few days ago are minimal but exhaustive, it's all there. The discrepancy between quantities of two different TFs may be of two types: shortage and excess. The first case is not terrible, but I will check the second one for overflow and try to limit it, if something is wrong. But it also stalls if the bars copied from another timeframe are smaller than the number of bars in the current one.

Fourthly, the indicator has been baked and verified for about a week already, it hasn't shows any obvious errors (neither at compilation nor during operation), there are only some implicit problems, one of which is the initial non-drawing of bars in certain TFs and sharp increase of calculation time on M1 when re-switching to it (during the first time everything is calculated within 2-3 seconds). The indicator seems to choke up in calculations (avalanche memory leak?) I have limited the number of copied elements using CopyBuffer - to 200 instead of the entire history, but it hasn't changed the situation. I've noticed, that offline on M1 and everywhere else the calculation is always fast, as for the first time, online the situation changes dramatically (probably, the problem is in that very filter, which skips something on every tick, although it shouldn't be, because redrawing frequency depends on redrawing a new zero bar and can't be earlier than the youngest preset TF in one of the handles). Small but unpleasant problems: the slightest attempt to scroll the chart with the mouse wheel dematerializes all fractals and we have to wait until they are recalculated and drawn (although no new bars arrived, there seems to be nothing to recalculate).