Errors, bugs, questions - page 249

New comment
 


alexluek:

There was no loss of communication, overdrawing on ticks, and the bigger the TF the rarer.

And the method of calculation from start date to end date (I found out that there are 3 of them) without

Probably it happens (it recalculates all the bars), but it is not yet accurate and I don't know how to check it.

but it's just a thought - let's check it...

Maybe there is another approach to avoid it...


Yedelkin:

Of course there is an approach. If(prev_calculated==0), we perform initial calculation for all bars. Subsequently, for each new tick (if 0 < prev_calculated < rates_total) we perform calculations like for(int i=prev_calculated-1;i<rates_total;i++) only for last appeared bars.


Still re-draws. Implemented this way:


int calculated1=BarsCalculated(StdDev1Handle);

...................

if(CopyBuffer(StdDev1Handle,0,0,to_copy,ExtStdDev1Buffer)<to_copy)return(0);

......................

int data1=CopyOpen(Symbol1,0,0,rates_total,Open1Buffer);

.....................

for(int i=rates_total-2; i>=0; i--)
{
if(time[i]>=DateStart)

{


It redraws then does not, but maybe it is about correctness of the code's work

but not in the terminal (but at least it's not so distinctive now...)

Ticks or no ticks may still redraw.

The impression is that there is no coherency (cause-and-effect relationship).

The only thing that comes to mind is a weak processor or a hang-up

The only thing that comes to mind is a weak processor or terminal freeze (MT5).

 

alexluek:

...................

It redraws then it doesn't, but it's all about code correctness

and not in the terminal (at least it's not so distinctive now...)

Please send a request to the Desk service with the source code, we will figure it out.
 

Has anyone worked with the second version of the ChartGetInteger function :

2. Возвращает true или false в зависимости от успешности выполнения функции.
В случае успеха значение свойства помещается в приемную переменную, 
передаваемую по ссылке последним параметром.

bool  ChartGetInteger(
   long    chart_id,        // идентификатор графика
   int     prop_id,         // идентификатор свойства
   int     sub_window,      // номер подокна
   long&   long_var         // сюда примем значение свойства
   );

? It seems that the value of the property is not passed to the receiving variable. At least, this behaviour is noticed when using the construct

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))
The function returns true, but the variable windows contains the value obtained during initialization of this variable. In this case, the first version of the function outputs a correct value. (And one more trivial thing: if the fetching variable is declared of the long type, the compiler generates a warning.)
 
Yedelkin:

Has anyone worked with the second version of the ChartGetInteger function :

? It seems that the value of the property is not passed to the receiving variable. At least, this behaviour is noticed when using the construct

The function returns true, but the variable windows contains the value obtained during initialization of this variable. In this case, the first version of the function outputs a correct value. (And one more trivial thing: if the fetching variable is declared of the long type, the compiler generates a warning.)
Yes, there is such a thing. Only I was trying to request the background colour. I wanted to write to servicedesk, but forgot.
 
Lizar:
Yes, there is such a thing. Only I tried to ask for the background colour. I was going to write to servicedesk, but I forgot.
Okay, I will.
 
Yedelkin:

Has anyone worked with the second version of the ChartGetInteger function :

? It seems that the value of the property is not passed to the receiving variable. At least this behavior is observed when using the construct

The function returns true, but the receiving windows variable contains the value obtained during initialization of this variable. In this case the first version of the function outputs the correct value. (And one more small thing: if the receiving variable is declared with the long type, the compiler will generate a warning).

It sounds like you are using a wrong function. This is the first variant of the function (with three parameters). It does not return true (as you think), but the value of the parameter

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))

I don't see your code, but it seems to be correct:

long Chart=0,windows;
if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,0,windows))
  {
   //--- всё плохо
  }
 
uncleVic:

You seem to be using the wrong function. This is the first version of the function (with three parameters). It does not return true (as you think), but the value of the parameter

I don't see your code, but it seems to be correct:

Hmmm..., yes, I had this exact bug - looked at my old code where I was trying to use this function.
 
uncleVic:

You seem to be using the wrong function. This is the first version of the function (with three parameters). It does not return true (as you think), but the value of the parameter

OK. Let's look into it.

1. The function is used "that", because you cite a function with the same name as your example. It can only be a question of which version of that function (first or second) is being used.

2. Indeed, formally the first variant of the function has three parameters, while the second has four. However, in the description of the sub_window parameter, which is present in both variants of the call, it is clearly stated that "Most properties do not require the subwindow number". Question arises: is it necessary or not required to indicate the window number for such property as CHART_WINDOWS_TOTAL (Total number of chart windows including indicator subwindows)?

3 It is logical to assume that specifying the number of windows/subwindows of the chart separately is not required in order to get the total number of windows/subwindows. This conclusion is supported by the example directly from the Handbook itself ( Charts Properties section):

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);

A similar approach is outlined in the Chart Operations / ChartWindowOnDropped section.

From these examples, it can be seen that the position of the Handbook authors is that it is not necessary to specify a separate subwindow number to get the total number of windows/subwindows in a chart. Of course, the examples use the first variant of the function, but since we're talking about the same property (that is, CHART_WINDOWS_TOTAL), it would be logical to suppose that the same conclusion holds true for the second variant of the function. Especially if you take into account that the Handbook does not contain any reservations about the necessity of specifying a zero subwindow number for the second variant of the function.

4. Your example suggests that the third parameter(sub_window) should always be specified for the second variant of function, even if the property itself does not require specifying a subwindow number. I.e., unlike the first variant of the function (which can be used both with two and three parameters), the second variant of the function always requires all four parameters. Right?

5. If correct, we've established two things. First, my original version of the problem turned out to be wrong. Secondly, the reason for this erroneous version is that the information in the Handbook is incomplete. Therefore I propose a clarification to the Handbook that "There is no default value for the second option, so the subwindow number must always be specified. For most properties that do not require a subwindow number, it is required to specify 0 (main chart window)". Or something like that.

Thanks for the example. It's short and to the point.

 
Yedelkin:
In the first variant of the function intsub_window=0 has a default value, so it can be omitted; in the second var iant there is no such default value, so it must be specified.

 
Yedelkin:

OK. Let's sort it out.

1. The function used is "that", because you cite a function with the same name as your example. It can only be a question of which version of that function (first or second) is being used.

2. Indeed, formally the first variant of the function has three parameters, while the second has four. However, in the description of the sub_window parameter, which is present in both variants of the call, it is clearly stated that "Most properties do not require the subwindow number". Question arises: is it necessary or not required to indicate the window number for such property as CHART_WINDOWS_TOTAL (Total number of chart windows including indicator subwindows)?

3 It is logical to assume that specifying the number of windows/subwindows of the chart separately is not required in order to get the total number of windows/subwindows. This conclusion is supported by the example directly from the Reference Manual itself (section Chart Properties):


1. Considering the fact that the function is actually overloaded, we can argue that it is not (although, as you can imagine, it is debatable);

2. that's the point. If I understand the logic of function overloading in MQL5 correctly, the first option can be used with 2 or 3 parameters, while the second one can be used only with 4 parameters.

That is, if a function receives two or three parameters, MQL5 will use the first option, while it will always use the second one if it receives 4.

The point is that the compiler gets confused in its calls if we use the second variant with a parameter number not equal to 4.

3. There is a small inaccuracy in the Reference (or rather a slightly wrong wording). The general sense is the following - most properties do not require a window number, and in the first option for such properties, the window number can be omitted(in the second option it must be specified, but it will be ignored).

4. From the above it follows that for this example the compiler will choose the first variant of the function.

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);
The compiler will make such a conclusion on the basis that the third parameter in the first variant can be omitted, while in the second variant it must necessarily be present!!!
1...242243244245246247248249250251252253254255256...3189
New comment
Reason: