Init() and DeInit() execution sequence - page 5
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I do understand that. I was asking about the logic of the sequence of operations. And here we are missing it. Sometimes OnDeinit is executed first (as it should be according to the logic of a layman) and sometimes OnInit is executed first.
I understand that the answer lies in the line"For some time (a very short time) both copies of the indicator exist in parallel." But this does not make the question any clearer.
The OnInit function must be executed first in the program.
Can you give an example when OnInit -> OnDeinit sequence is not always executed?
The OnInit function is supposed to be executed first in the program.
Can you give an example when OnInit -> OnDeinit is not always executed?
You can use an example of the author of the themeERROR.mq5, which he gives in the beginning. Switch the TF and see what happens in the Experts tab.
You can use the exampleERROR.mq5 he gives in the beginning
I'll try it out in the course of the day. Have you personally used it yet?
Of course, I used it 9 months ago. You can read my comment at #8 in this thread.
Er, no, it's not that simple. Indicators sit inside another entity, the chart/chart, and are subordinate to it (I'm aware of their complex one-to-many relationship, but it doesn't change the point). A chart has its own life cycle, which includes some kind of internal init and deinit events, which are the boundaries for the life cycle of the indicators. In other words, an indicator cannot outlive its chart. The chart's deinit must wait for the deinit or timeout of deinit of all indicators. Only then the chart init for the new timeframe can be started, and from it the inits of the attached indicators can be called.
Charts are the same as indicators. Indicators can 'outlive' their charts.
Before OnInit of an indicator/advisor the constructors of the global objects are executed. After OnDeinit - the destructors. Therefore, you can remove OnInit and OnDeinit from any indicator.
The only problem is not matching of your ideas about the indicators with reality. Perhaps, this behavior is critical for some freelancers who cannot write the solution.
I would welcome a step forward on this topic from the developers. But here two completely understandable points of view collide with each other with their own logic, as it should be. Neither of them is more flawed than the other. It's just that some think it's right this way and others think it's right that way.
Imagine how slow the charts would be if before changing the TF the terminal waited for the unloading of all indicators from the old TF and only then built and initialized the new one.
In what situations, besides the straightforward work with graphical objects (without the name of TF in the name) is the DeInit - Init sequence important?
Imagine how slow the charts would be if before changing the TF the terminal waited for the unloading of all indicators from the old TF and only then built and initialized the new one.
In what situations, besides the straightforward work with graphical objects (without the name of TF in the name) is the DeInit - Init sequence important?
+
Once again. When you change timeframe or symbol in the chart, a new copy of the indicator is created. A new one.
For the same reason that the calculated parts of the indicators live in the history caches. For each timeframe has its own cache of bars. When you change timeframe, say EURUSD,M1 on EURUSD,H1, to the indicator in the cache M1 is sent event Deinit with cause 3 (chart change) and after a while this indicator will be unloaded. If suddenly this indicator didn't have time to handle Deinit with reason 3, it will be deinitialized with reason 1 (chart close). If the H1 cache didn't exist at that moment, then it will be created. After that, the NEW indicator copy is loaded to the H1 cache, to which the Init event is sent. The new copy of the indicator doesn't know anything about the previous copy, which is about to die. All variables of the new copy of the indicator are clean, they are newly born.
If there is a timeframe change within a single symbol, the order of initialization/deinitialization is in principle predictable. Download the latest build 1580 - we have corrected some things there, now deletion of indicators is performed in the very last turn, so there should be no premature deiniteration. But if you change the symbol, you get inter-thread race in a pure form and you can not predict the sequence of initialization-deinitialization unambiguously. Since different characters are processed in different threads
Therefore a tip for the topic-starter. Focus on the cause of deinitialization. If it is 3, then you don't need to return the colour scheme to the graph
Imagine how slow the charts would be if before changing the TF the terminal waited for the unloading of all indicators from the old TF and only then built and initialized the new one.
In what situations, apart from the straightforward work with graphical objects (without the name of TF in the name) is the DeInit - Init sequence important?
Why would they be slow? Unless the indicator is written incorrectly. For a well-written indicator DeInit takes quite a short time. Moreover, TF switching is not such a frequent operation. In some especially serious cases (for "wrong" indicators) you can wait a second or two when changing TFs.
Therefore, the argument about braking during TF switching is more than dubious. Besides, when you switch to the TF that has not been built yet, the time delay is rather palpable. And nobody cries about the brakes of the terminal.