Init() and DeInit() execution sequence - page 10
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 have clearly written - keep the data required for copying always up-to-date, don't just do it when initing, always keep it up-to-date.
Andrey, are you kidding or do you really not understand that all your actual data stored in variables and arrays in the indicators become irrelevant after the change of TF because the indicator copy with all its details is deleted. In Expert Advisors, of course, everything is simple, because there is no reinitialization.
You must be kidding or you don't understand that all your actual data stored in variables and arrays in the indicators become irrelevant after the change of TF because the indicator copy with all its details is deleted. In Experts, of course, everything is simple, because there is no reinitialization.
No, I'm not.
You don't understand what I'm saying.
For example, there is a certain data set that needs to be transferred to another copy of the indicator (whether it is another indicator thrown on a chart or a new copy of the indicator when the TF changes, it doesn't matter). The indicator calculates something and every time it calculates something and this something will be applied to other indicators, this indicator should update. Each time. This database can be stored in different places, depending on the amount of data and the required communication speed. This data needs to be updated whenever necessary after a change is made to the data, not just when it is deinitialised. That's the trick. There is nothing complicated about it. It's not about storing the data in the local variables of the indicator, it's about resetting/updating the data each time the data has been re-calculated.
But with the graphical objects it is very simple.
In Expert Advisors, of course, everything is simple, because there is no re-initialisation.
No, I'm not.
You don't understand what I'm saying.
For example, there is a certain data set that needs to be transferred to another copy of the indicator (whether it is another indicator thrown on a chart or a new copy of the indicator when the TF changes, it doesn't matter). The indicator calculates something and every time it calculates something and this something will be applied to other indicators, this indicator should update. Each time. This database can be stored in different places, depending on the amount of data and the required communication speed. This data needs to be updated whenever necessary after a change is made to the data, not just when it is deinitialised. That's the trick. There is nothing complicated about it. It's not about storing data in local indicator variables, it's about resetting/updating the data each time the data has been re-calculated.
And with graphical objects, it's quite simple. There's no need to even explain.
It's very debatable about nothing being complicated. Try to really replicate on the example of a simple waving machine what I have implemented in this product. In the wristwheel you change the period with the mouse and then, when you change TF, the changes should be saved, and it is possible to use several indicators in the window. And you will see that there is nothing complicated. And if you need to pass an array. And you will see how "simple" it is. Perhaps I would think so myself, if I haven't implemented it already.
It's very debatable about nothing being difficult. Try to really replicate on the example of a simple wrecker what I have implemented in this product. In the wristwheel you change the period with the mouse, and then, when you change TF, the changes should be saved, and it is possible to use several indicators in the window. And you will see that there is nothing complicated. And if you need to pass an array. And you will see how "simple" it is.
I have only recently learned that all variables in EAs are preserved during reinitialization, i.e. I wrote EAs the same way as indicators, assuming that the program knows nothing about other programs, for it there is only their init and deinit, the program must not know about other programs' init and deinit.
This is why I never rely on the time consistency of the ininit and deinit of the program to be unloaded and run again, I used to never rely on the fact that it can change sometime (in 1580 it has changed). Relying on undocumented bugs and platform futures can backfire in the future.
In my practice, there are also products that dynamically change the visualization depending on the user's actions, applying everything - from events to exchange files. There are much more indicators on the chart than 1 as a rule, the indicator buffers in 5 are unlimited and you can create them as a parameter during the startup. I.e. we are creative people, we need to have flexible approach to solve our tasks and at the same time keep in mind specifics of 3 kinds of programs, but platform developers are concerned with other issues, which are more important than minor difficulties in comparison with global tasks of the platform.
There are really important defects in the platform, about which they don't talk much or not at all, it's much more important than the farfetched problem of "inits and deinserts".
If the timeframe is switched downwards, then first OnInit on the lowest (new) timeframe and then OnDeinit on the highest (old) timeframe.
If the switch goes 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 the lowest to the highest timeframe
This is just awful. Application programmers must not think about such systemic things. The platform can handle the caches internally however it wants, but at the MQL level it must transparently bring everything into a single event contract, without potential side-effects. All references to alleged efficiency considerations and the possibility for everyone to work around the problem by themselves are simply untenable. It is possible to do both effectively and conveniently (eliminating the possibility of stepping on this rake altogether), once and for all.
That's right, they shouldn't. So you run Total Commander, for example. Why demand from Microsoft that Windows takes care of the "correct" sequence of uploading/downloading TC copies to RAM? Is that a concern of the OS?
The concern of OS is that TC doesn't interfere with other TCs and what they do there in RAM, exchange files or whatever else is their business.
"I think so!" (c) Mimino, 1977.
I would like to summarise and summarise the above. So, before the release of the 1580 build of MT5 (current build 1571), what do we have?
In the indicators, unlike the Expert Advisors, when the TF changes, because"a new copy of the indicator is created, that doesn't know anything about the previous copy", all variables are re-initialized, besides the execution order of OnDeinit of the old TF and OnInit of the new TF is unpredictable, regardless of whether the TF is "up" or "down" (practice, contrary to what was mentioned by Mr. Slava). In this connection programmers have a number of problems and uncertainties. For example:
- the programmer, who hasn't read this topic when creating an indicator for something in OnInit, creates an object, logically checking before the creation of the object with this name. Also it is logical to prescribe the removal of this object in OnDeinit. When TF is changed, if first OnInit of new TF is executed, it checks for existence of object, it turns out that it already exists, and it is not created, because it is already created. After that OnDeinit of the old TF is performed and the object is removed. The programmer is in a state of shock. Where is my object and why is it gone? He will get even more confused, when the next time the TF is changed, when the sequence of OnInit and OnDeinit is different, the object is not removed. It's deleted, it's not deleted.... After a long research will start to address to Service Desk, new topics on the forum about the old one.
This is only the simplest situation. There will be others as this feature is not described in the documentation and you can only read about it on the forum.
If you want to create something special and pass some parameters from the old copy of the indicator to a new one, when you change the TF, you cannot use OnDeinit, because of the unpredictable sequence of initialization and deinitialization operations. In myopinion, the best solution in this case is to use the following tools:ResourceCreate based on the pixel array andResourceReadImage, but it's quite cumbersome and you need to take care of resources conflict, if you use several identical indicators in one window, and every time the data you want to send for another copy needs to save it in a non-reinitialized resource, because the time of possible change of TF is not known for the application. I've implemented this long ago (e.g. in this product), so I know what I'm talking about. Implementation of data transfer through files and global variables of terminal is less successful solution (IMHO).
If the new build 1580 will belike Slava says, it won't make the task easier, because deinitialization of the old copy of the indicator will be performed after initialization of a new one. But there will be no uncertainty.
We have to hope that the developers paid attention to this problem since they are trying to fix it.
We are waiting for a new build.
I completely agree that this processing feature MUST be mentioned in the documentation, otherwise new arrivals will face this problem and come to forums looking for a solution. (Why, when you can tell them about it right away in Terminal and MQL docs).
Also add to the documentation that the log does not show a complete picture of the events, but only a part of it. See full logs for complete picture.
About the rest later ...
I would like to summarise and summarise the above. So, before the release of the 1580 build of MT5 (current build 1571), what do we have?
In the indicators, unlike the Expert Advisors, when the TF changes, because"a new copy of the indicator is created, that doesn't know anything about the previous copy", all variables are re-initialized, besides the execution order of OnDeinit of the old TF and OnInit of the new TF is unpredictable, regardless of whether the TF is "up" or "down" (practice, contrary to what was mentioned by Mr. Slava). In this connection programmers have a number of problems and uncertainties. For example:
- the programmer, who hasn't read this topic when creating an indicator for something in OnInit, creates an object, logically checking before the creation of the object with this name. Also it is logical to prescribe the removal of this object in OnDeinit. When TF is changed, if first OnInit of new TF is executed, it checks for existence of object, it turns out that it already exists, and it is not created, because it is already created. After that OnDeinit of the old TF is performed and the object is removed. The programmer is in a state of shock. Where is my object and why is it gone? He will get even more confused, when the next time the TF is changed, when the sequence of OnInit and OnDeinit is different, the object is not removed. It's deleted, it's not deleted.... After a long research will start to address to Service Desk, new topics on the forum about the old one.
This is only the simplest situation. There will be others as this feature is not described in the documentation and you can only read about it on the forum.
If you want to create something special and pass some parameters from the old copy of the indicator to the new one, when you change the TF, you can't use OnDeinit, because of the unpredictable sequence of initialization and deinitialization operations. In myopinion, the best solution in this case is to use the following tools:ResourceCreate based on the pixel array andResourceReadImage, but it's quite cumbersome and you need to take care of resources conflict, if you use several identical indicators in one window, and every time the data you want to send for another copy needs to save it in a non-reinitialized resource, because the time of possible change of TF is not known for the application. I've implemented this long ago (e.g. in this product), so I know what I'm talking about. Implementation of data transfer through files and global variables of terminal is less successful solution (IMHO).
If the new build 1580 will belike Slava says, it won't make the task easier, because deinitialization of the old copy of the indicator will be performed after initialization of a new one. But at least there will be no uncertainty.
I hope the developers have paid attention to this problem since they are trying to fix it.
We are waiting for a new build.
The Expert Advisor works fine when switching the TF, and the indicator in this situation works very differently.
No problem if you are aware of this undocumented feature and only deal with the simplest case - graph. objects. I mean those who do not know this feature, I think this topic on this forum will be read by a very small percentage of programmers and I just pity their time to figure out all the nuances. I had been in this situation before I understood the essence.