ForumSections

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

New comment
Slawa:

No solution means "not yet known how to solve", not "won't"

And with user events there is no problem at all

Phew... You're scaring me :)
fxsaber:

How can Services or the ability to run multiple EAs on a single chart not fully cover the problems discussed?

Well, the problems will remain. Just because there will be a new MQL-program type, it does not solve the problems in other types of MQL-programs. Good software does not allow user to make a mistake. Writing a phrase about uncertainty of behavior in the help is easier, of course. It is up to the drowning people to save them.
Stanislav Korotky:
It is up to the drowning people to save them.
One can, of course, continue to lament that the rock continues to fail to contribute to the drowning man's salvation when a lifeline is thrown.
elibrarius:
I suggest deleting everything from post 125 onwards as irrelevant to a constructive discussion on deinit and init queuing when changing TFs.
It would be better to delete the whole thread. And forget about it like an unpleasant dream.
Dmitry Fedoseev:

One indicator does have first initial, then deinit. But when the timeframe is switched, the second indicator instance is created, and its init may be executed earlier than the deinit of the previous (uncharted) instance.

The most obvious example - the saving of user parameters when switching the timeframe - we save parameters in the deinit, read them in the init. If the init of the new instance is triggered before the previous instance's deinit, the parameters will not be saved.

Practically, the deinit of the deleted instance generally triggers before the init of the new instance, but if the timeframe is switched very quickly or the data is loaded, then a failure occurs.

Dimitri, when driving a car, do you have to look in the rear-view mirror when you have already arrived? Or do you have to periodically save the required parameters in the indicator. It's like looking in the rear-view mirror.

fxsaber:
You can, of course, continue to complain that the stone continues to not contribute to the rescue of a drowning man when a life preserver is thrown.

The rake remains. That's the main thing. (in this analogy, a lap is given out at a boatyard on demand, and people drown at random and unexpectedly).

If the old chips aren't all right, the new ones will be too. The approach doesn't change.

All in all, I have stated everything, imho, more than reasonably and logically. If anyone is in the tank, I can't help.

Stanislav Korotky:

If the old features aren't all right, the new ones will be too. The approach doesn't change.

The question here is whether they can't or won't? It looks like they can't.
Slawa:

In other words, the order of OnInit and OnDeinit execution of the indicator when changing the symbol-periodof the chart should not bother anyone

OnInit starts the timer, onDeinit deletes it. As a result of wrong queue, no one knows what's going on.

Unpleasant bug, which is blatantly ignored by the developers

Комбинатор:

Init starts the timer, in deinit deletes it. As a result of the wrong queue, don't know what's going on.

A nasty bug that is blatantly ignored by the developers

The queue is unambiguous.
fxsaber:
The order is unambiguous.

When you change thef.

If the indicators still have garbage in the buffers from the old TF, maybe the timers will be affected as well.

1...121314151617181920212223242526...28
New comment