Init() and DeInit() execution sequence - page 13
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
...
Several people have already asked for a specific example of a task that is problematic within the indicator execution paradigm in MT5. Will there or will there not be a clear example, not sucked out of thin air?
One indicator does have first initial and 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 removed instance is mostly triggered before the init of the new instance, but if the timeframe is switched very quickly or the data is loaded, then a failure occurs.
And now imagine that there is not one single event queue, but rather a queue for each symbol-period. There are as many symbol-periods as there are queues.
Now suggest the order in which the queues are handled.
In my opinion the queue should be tied to a chart. Whether the user changes a symbol, TF or just closes it, all the indicators should be completely finished, then the EAs, with processing of all the commands in deinitions (whatever they do, writing to global variables, files, deleting objects, interacting with DLL, sending something to the Internet) and after completion and unloading from memory - run new instances on a new TF or symbol, not knowing anything about the previous one, but being able to correctly read the information saved the previous one.
It will probably be a little slower, but it will be the right thing to do.I'm in favour of programs that work correctly, not fast and wrong.
If the new instance's initiate is launched earlier, then it turns out that deinit is not necessary at all and is even harmful because it will mislead programmers because they hope that they will save something and then count it. If we leave it as it is, then add to the help - that the results of this function will not be known to the next The results of this function will not be known to the next instance, i.e. no one will do anything in this function. And even better - delete it, if the natural order of events is very difficult to do and will require you hundreds of hours of work.
If the timeframe switch goes down, then first OnInit on the lower (new) timeframe and then OnDeinit on the higher (old) timeframe.
If the switch goes up, it's vice versa. First we start 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
Quite a strange logic! What should I do? If there will be some parameters written to the disk in DeInit, which should be read and picked up in OnInit during the next indicator start, even if it is started in the lower timeframe.
I guess I need to write a short test to check it. In fact, if the function switches to a lower timeframe, the logic will be more than fine.
In general, it's a pity that static variables are not saved in indicators, at the same time the Expert Advisors are great with static.1. What do you call desktop applications? I have a feeling that MT5 is not a desktop application...
2) I'm not making this up. This is the topic of the current thread. The point is that MT5 can execute Init for the indicator that has not yet DeInit. Yes, it is. Haven't you read the topic?
3.Try to update the same file several times per second and share your feelings.
4. What does this have to do with adding 1 to the name? It's about the fact that there are graphical objects from the same indicator, but different copies of it, on the screen at the same time. Technically there is no conflict. There will be a conflict for the user who sees the chagrin on the screen until the old copy is deleted.
5. Let me let you in on a big secret: there is one copy of the DLL per terminal copy. You cannot use multiple copies of them.1. We are not talking about MT5, we are talking about indicators (like scripts and experts) which are not run in the operating system, but in a special secure environment.
2. You are contradicting yourself. If the recalculation is performed so quickly (several times a second), then there is no problem to perform a new recalculation in a new copy of the indicator. In this case it makes sense to reset the running data periodically after a set time (you can use ontimer or custom counter for this). And if calculations are long, the more it is necessary to save the data after the calculations to avoid their loss in case of force majeure (mother removed the plug from the socket "to avoid phonation").
3. The old copy will be deleted in less than a second, and with it its graphobjects. What kind of moron would switch TF with such a frequency that flicker would be observed? - So what? dll can't be removed from the copy in less than a second.
4. so? the dll may be busy, it is normal. You don't have to worry about it; you just have to repeat the request in a second, for instance.
As you can see - no problem, you just need to handle the programs in the MT terminal correctly, remembering that they are not desktop applications and that they run in a special protected environment.
One indicator does have first initial and 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 removed instance is triggered before the init of the new instance, but if the timeframe is switched very quickly or the data is loaded, a failure occurs.
Here we go again... Why "switch timeframes very quickly"?! Do any of you turn on (or turn off) your computer "quickly by pressing the button" Power?
Why? Does the criminal code prohibit it or the constitution?
Why? Does the criminal code prohibit it or the constitution?
There's a lot of things the AC doesn't forbid, like sticking your fingers in a socket.
Give an example of the need for frequent switching of the TF so fast that objects start to flicker. - Do not give an example of the hypnotic effect, because it can be achieved by more efficient methods.
There are a lot of things the regulator does not forbid, like sticking your fingers in a socket.
Give an example of the need to switch the TF so often that objects start to flicker. - Do not give an example of the hypnotic effect, because it can be achieved by more efficient methods.
Because the socket and plug were designed by sensible designers, not idiots. On the voltage side is the socket, not the plug. In addition, the holes in the socket are so large that you can't put your finger in there. But you can do it your own way in your own home - let the plugs stick out of the wall and the sockets hang from the wires. You understand and won't touch plugs protruding from the wall with your hands.
OK. The sockets are an unfortunate example.
Then let's take another one - jumping off the balcony! Does the AC forbid jumping off the balcony? - No? - Then why don't you practice it for the adrenaline rush?
All goals must be achieved by sensible means, otherwise the goals are not sensible.
Andrey Dik:
Give an example of the need to switch the TF frequently so fast that objects start to flicker. - Do not give an example of the hypnotic effect, as it can be achieved by more efficient methods.