Errors, bugs, questions - page 239

 

The chart has just been 'updated'. And it's the same again:

 
Yedelkin:

The chart has just been 'updated'. And it's the same again:

Urgently write to servicedesk and do not close the terminal
 
AlexSTAL:
Write to servicedesk urgently and keep the terminal open
OK, I'll bluntly copy the link to this thread.
 

Just checked in the terminal - the EURUSD M1 chart is completely present at the specified location with no gaps.

Try giving the "Refresh" command from the context menu of the chart.

 
Renat:

Just checked in the terminal - the EURUSD M1 chart is completely present at the specified location with no gaps.

Try giving the "Refresh" command from the context menu of the chart.

Refreshed manually, thank you. Since I practically do not work with charts, I have a question: How can I update the base of the minitables at the Expert Advisor level in such a situation? The terminal only works with the database it has. Should I integrate the function to check synchronization?
 
Renat:

Just checked in the terminal - the EURUSD M1 chart is completely present at the specified location with no gaps.

Try giving the "Refresh" command from the context menu of the chart.


I think there is a floating bug somewhere.... Since I'm not the only one who has about the same situation going on....
 
Yedelkin:
It was updated manually, thank you. Since I practically do not work with charts, I have a question: how to update the minute base in such a situation? The terminal only works with the base that it has. Do I need to integrate the function of synchronization check?

I memorised the time of loss and resumption of communication in the timer.

Having this information, you can try to download the history for the period (you can also check synchronization with the server, if it makes sense).

 

Gentlemen developers, I am speechless. I have faced a problem with local variables "wiping" in the object method after internal call of the same method from another object. May be it is related to some optimization in nested function calls of objects, but at least there are no errors in log and no memory leaks. I cannot quote a large code, but the meaning will be clear from the examples in principle:

variant 1

bool operate(CAlgoBlockLogic* s1, CAlgoBlockLogic* s2) {
 bool d1 = s1.process();
 bool d2 = s2.process();
 return (d2 && d1);
}

variant 2

bool operate(CAlgoBlockLogic* s1, CAlgoBlockLogic* s2) {
 return (s2.process() && s1.process());
}

Ideally, the code should work exactly the same. But... the variants work differently.

Thus. Variant 1 does not work correctly. I ran a record in the debug file and found out that the variable d1 defined in the operate function is overwritten with the value of the d1 variable in an inner call of the same operate function but in another object of the same type. I.e. in short. after calling
 bool d2 = s2.process();

Variable d1 changes its value to the one that occurred in the internal operate call inside s2.process. This behavior is the same as when changing the value of a static variable for objects of the same type. But here the variable clearly has a local scope.

The issue of static variables was brought up in this thread and everything is clear. But what to do with uncertainty of local variable values?

Документация по MQL5: Основы языка / Переменные / Область видимости и время жизни переменных
Документация по MQL5: Основы языка / Переменные / Область видимости и время жизни переменных
  • www.mql5.com
Основы языка / Переменные / Область видимости и время жизни переменных - Документация по MQL5
 

"...variable d1 defined in operate function is overwritten by the value of variable d1 in internal call of the same operate function, but in another object of the same type. I.e. in short. after calling
bool d2 = s2.process();
variable d1 changes its value to that which occurred in the internal operate call inside s2.process."

Sounds like either a hidden recursion, with the usual set of side-effects, or ...

 
Vigor:

In theory, the code should work exactly the same. But... the variants work differently.


No. It is not identical.

In the first case s1.process and s2.process are called unconditionally

In the second variant, s1.process will only be called if s2.process returns true. This is called "shortened condition evaluation".

Reason: