Init() and DeInit() execution sequence - page 7

New comment
 
Slawa:

If there is a timeframe change within one symbol, then the order of initialisation and deinitialisation is in principle predictable. Download the latest build 1580 - we have corrected some things there, now the indicators are removed last, so there should be no premature deiniteration.

I don't get it. Please clarify. Deinit will be guaranteed after init?
 
Andrey Khatimlianskii:

Indicators come in all shapes and sizes. Braked ones too. And not all of them are their own and in source code.

A couple of seconds is funny. The interface feels tens of milliseconds, discomfort immediately appears.


Don't get it twisted. It's not about the interface, it's about the transients - TF switching. On a blank chart does TF switching take an infinitesimal amount of time? No. Then the indicators have nothing to do with it.



And most importantly, there is no answer to my question:
In what situations, apart from straightforward work with graphical objects (without a TF name in the name), is the DeInit - Init sequence important?


In almost all situations. Unless, of course, we deal with MAshek type toys and similar primitives:

  1. Writing to a file. When at disconnection of the indicator it is required to save the accumulated information in a file. Because it is impossible to keep the file open all the time. There is a risk of crashing and loss of all information recorded into the file.
  2. When working with graphical objects. It is a real beauty: one indicator still exists and hasn't cleaned up, while the second one is drawing over these objects. That is how we will explain to the user: "When switching the TF you will observe short-term disturbances". )))
  3. Working with DLL. When Deinit DLL must interrupt all the threads, that have been created by it. The next indicator copy after that recreates them for itself. Now we get that the new indicator copy will try to create all these threads and it will be rejected, because they are still running. The new indicator will generate an error message and will not work. Just because of TF switching. Yes, the problem is solvable.

Agreed. Problems other than the second one are solvable if you know about them. That is, we must now shove all the logic into OnCalculate, while Init and DeInit should not be used. But what for do we need them then?

Anyway, we are not talking about cross-platformity now. It turns out that MT4 and MT5 have different approaches to Init and DeInit.

 
nmaratr:


If it wasn't about finances, perhaps there wouldn't be such a discussion.

And since a trading advisor depends on one indicator or the other, it will simply stop working properly because of a simple switch of the TF. That's what's most stressful.

So how can you entrust it with your finances?

We may be at odds with the MT developers on this issue.

There are a lot of options to solve this problem. And almost all of them have been voiced in this thread.

1. If the indicator is written using the Expert Advisor, the Expert Advisor should be written in such a way that it is not affected by period changes of the chart. Hence, the indicator will not be reinitialized.

2. If you have to delete graphical objects or change the design of the chart in deinit, then check the reason for deinitialisation.

3. If the indicator needs to save some parameters, then, as has been voiced here, do not save this data at deinit, but when this data is prepared or changed.

4) Out of two piles of crap, always choose the one that stinks less. Accordingly, when choosing between the speed on which ALL indicators depend and the complexity of saving some data in SEVERAL indicators, I choose speed.

 
Stanislav Korotky:
I don't understand. Please clarify. Will the deinit be guaranteed after the init?

If the timeframe switch goes down, first OnInit on the lower (new) timeframe and then OnDeinit on the higher (old) timeframe.

If the switch is going upwards, then it is vice versa. First OnDeinit on the lower (old) timeframe, and then OnInit on the higher (new) timeframe.

Here we should keep in mind that the caches are processed from the lowest to the highest timeframe

 
Slawa:

Download the latest build 1580 - we've fixed some things there, now the indicators are removed last, so there shouldn't be any premature deiniteration.


:(( Oh man, that's "good news". Now I may have to rewrite the code in some programs, because it was designed for "the other way round" - first Deunit, then Unit.
To be honest, it is a strange logic. It means that the old and the new indicator copies will unambiguously live together for some time, until the first one executes the unit in the new indicator copy and the second one, until the last one executes the unit in the old one. At that time there is no possibility to inform the new copy about some information through Deunit. This is obviously a mess. For units are usually much more cumbersome than units. Why such a strange sequence of execution! Then this topic will be revived again and again. But if the programmer in the indicator could create some variables that are not reinitialized when changing the TF, then let's deal with this sequence of OnInit and OnDeinit. I've written about it a couple of times already(1 and 2). I agree with the developers' logic, that for security reasons the pointers and references are not a luxury for programmers, but if you create a mechanism of a special type of shared variables for all copies of the indicator, we will have to create the same mechanism for all copies of the indicator. The indicator is the same, the indicator properties are stored "somewhere".
 
Slawa:

If the timeframe switch goes down, first OnInit on the lowest (new) timeframe and then OnDeinit on the highest (old) timeframe.

If the switch is going upwards, then it's vice versa. First OnDeinit on the lower (old) timeframe, and then OnInit on the higher (new) timeframe.

Here we should keep in mind that the caches are processed from low to high

This is even more confusing.

After all, if the indicator is not used by the author himself, then he can switch as he likes without waiting for the init and deinit? And what will happen? And if for one variant of switch in deinit it is necessary to do some actions, then it does not make any difference whether it is written for one direction of switch or for both directions. But they have added brakes for the "heavy" indicators.

 
Alexey Viktorov:

This is even more confusing.

After all, if the indicator is not used by the author himself, then he can switch as he likes and without waiting for the init and deinit? And what will happen??? And if for one variant of switch in deinit it is necessary to make some actions, then it does not make any difference, if it is written for one direction of switch or for both directions. But they have added brakes for "heavy" indicators.

Where have the brakes been added? Compared to what have they added?

Please support your statements with code, so, everyone can reproduce it.

Once again. Since another copy of the indicator is created at the change ofthe symbol-period, the order of OnInit at the new symbol-period and OnDeinit at the old symbol-period is undefined

 
Slawa:

Where have the brakes been added? Compared to what have you added?

Be kind enough to back up your claims with code so everyone can reproduce

Once again. Since another copyof the indicator is created when changing a symbol-period, the order of executing OnInit on the new symbol-period and OnDeinit on the old symbol-period is undefined

In this message

Slawa:

If switching timeframes goes down, then first OnInit on the youngest (new) timeframe, and then OnDeinit on the oldest (older) timeframe.

If the switch goes upwards, then it's vice versa. First OnDeinit on the lower (older) timeframe, and then OnInit on the higher (newer) timeframe.

You should bear in mind that the caches are processed from a low-order timeframe to a high-order one.

Did you tell it like it is or like you did when preparing the new build?

If so, then I've got it wrong and I take it back.

 
Alexey Viktorov:

In this message.

Did you say as is or as done preparing a new build?

If as is, I misunderstood and take it back.

This is done in build 1580.

Before that, deinitialization at timeframe change was almost always earlier. But only if the timeframe switch goes down, the deinitialization was done with code 1, not 3, as it should be

 
Slawa:

This is done in build 1580

Before that, deinitialisation when changing timeframe was almost always before. But only if the timeframe switch goes down, the deinitialisation was done with code 1 and not 3 as it should be


Then how to process these codes of deinitialization in Inite of the indicator, what do these codes do? Because there is no possibility to wait in the indicator, Sleep does not work.
1234567891011121314...28
New comment