Init() and DeInit() execution sequence - page 9
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
Thank you for the code, of course. But EAs are fine in any case becausewhen I change TF they don't reinitialize variables, while indicators do. If you really want to help with advice, please "run" it again in less haste.
Nicholas, I ran across the topic, even when I wrote the first post. And I didn't find any discussion about how an EA behaves when the timeframe changes. Yes - the topic is mostly about indicators, while the author wrote in his post"An indicator or Expert Advisoris written ".
I've given an example that I checked and it works within the framework of the Expert Advisor. But you - then you reproach me for inconsideration, then you send me to reread the topic, then you discuss - what is reasonable or not reasonable. In addition, you may read the first page
It's not clear whether we are speaking about an Expert Advisor or an indicator. You don't even clearly say in your post that you are speaking about an indicator.
SEE AN EXAMPLE OF YOUR POST:
So, that's it?
I've been experimenting and using this reason code (REASON_CHARTCHANGE) to the fullest extent. But what good is it if all variables are set to their initial state and OnDeinit is executed after OnInit of the new TF?
Is it clear from what I just said that the variables are initialized in the indicator?
The person reading your post may think that the same thing happens in an Expert Advisor.
----
The answer to this question!"When you change TF, variable reinitialization does not occur, while it occurs in indicators".
you can save variable values somewhere, in globals for example...
If you want to use the OnInit method you have to read and restore the values in the same way.
------------
If you are interested only in the problem of changing the TF for the indicator - it doesn't mean that others, including me, are not interested in the option of changing the TF for the EA.
I can'tgive advices about the indicator, because I don't know how to do it on practice, but I will be observing the suggested solutions with interest.
I have understood that the developers are reading this topic and have even corrected some things in the build 1580. Perhaps they will offer solutions.
Didn't you read what I wrote several times?
There is no way in the indicators. You can't do it in five from the very beginning. Because you have to download a completely new copy of the indicator with all its consequences.
Thank you for your honest answer.
It has always been like that in 5. Maybe it is time to fix it?
Is it really so hard to do the right order? Saving time at the start then translates into endless checks on every tick.
I've already got used to the OOP paradigm of MT5 and I know where the rake is and how to fix crutches to bypass these rakes, of course if there are no new ones. It turns out it's easier to delete an object and create a new one than change a couple of parameters.
Similarly, in a car, instead of changing the oil and driving on, it is better to throw the car away and make a new one.
Reminds me of a cartoon:
Can you tell me please?
I've decided to write a program which
1. On Inite outputs 8 lines
2. On DeInite outputs 8 more lines.
I ran it in the tester (I ran it for 2 days and got it).
For some reason, it selectively fails to log some strings.
Is this also to speed things up???
------------------------------------------------------------------------------------------
QUESTION REMOVED BECAUSE THE FULL LOGS HAVE ALL THE INFORMATION
------------------------------------------------------------------------------------------
In the documentation it is necessary to add
1. The log does not show all the information the programmer expects
-------- IT IS ESSENTIAL TO SEE THE FULL LOG !!!
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. Then 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 threads 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 there will be no uncertainty.
I hope that developers paid attention to this problem since they are trying to fix something.
We wait for the new build.
All graph objects are named with reference to the current TF. At initialization we create, at deinitialization we delete. During operation of the indicator modify as needed.
Is there a problem here? No problem. Everything is normal from the moment of indicator start until the moment of its unloading.
We switch over the TF. It does not matter which way it goes, up or down. A copy of the indicator is launched. This is equivalent to the fact that the indicator has been launched for the first time on this TF.
Is there a problem here? There is no problem. The old copy will take care of removing its objects, and the new copy will create new ones according to the current timeframe.
What am I doing wrong? Why don't I see a problem?
All graph objects are named with reference to the current TF. When initializing, create, when deinitializing, delete. During operation of the indicator we modify as needed.
Is there a problem here? No problem. Everything is normal from the moment of indicator start until the moment of its unloading.
We switch over the TF. It does not matter which way it goes, up or down. A copy of the indicator is launched. This is equivalent to the fact that the indicator has been launched for the first time on this TF.
Is there a problem here? There is no problem. The old copy will take care of removing its objects, and the new copy will create new ones according to the current timeframe.
What am I doing wrong? Why don't I see a problem?
No problem if you are aware of this undocumented feature and only deal with the simplest case - with graph. objects. I mean those who do not know this feature, I think this topic is read by a very small percentage of programmers on this forum, and I just pity their time to figure out all the nuances. I had been in this situation before I understood the essence.
I have never heard of nuances such as those described in this thread, but I have never encountered any problems with the problems described here.
if you want to transfer something to another copy of the indicator, you don't need to do it deinit - keep the transferred data up to date during all the indicator lifetime - for example in the main variables of the terminal, then no matter the reason of indicator unloading (change of TF, mum pulled the plug "so it won't hum when everyone sleeps", earthquake, change of earth magnetic poles and so on.etc.) the next run of the indicator (including a copy when the TF changes) will get all the necessary information from this magical data source (for the unlucky cases of global scale you can keep the data on a cloud drive).
Guys, there is no problem at all.
All graph objects are named with reference to the current TF. When initializing, create, when deinitializing, delete. During operation of the indicator we modify as needed.
Is there a problem here? No problem. Everything is normal from the moment of indicator start until the moment of its unloading.
We switch over the TF. It does not matter which way it goes, up or down. A copy of the indicator is launched. This is equivalent to the fact that the indicator has been launched for the first time on this TF.
Is there a problem here? There is no problem.
There is a problem: simultaneous existence of objects from different indicators. "Sorry, we have temporary technical problems" (but this will be resolved in a few seconds when the old indicator DeInit happens)
The old copy will take care of removing its objects, and the new copy will create its new ones, naming them according to the current TF.
What am I doing wrong? Why don't I see any problems?
It's a narrow view. That's why you can't see. Broaden your horizons a bit. The first problems occur while working with the files, as it is not clear whether the previous indicator has had time to save data in the file or not yet. Some flags in the global variables of the terminal will have to be created. The new copy of the indicator will have to wait for the old copy to reset the accumulated data. By the way, the problem is that such synchronization is possible only in OnCalculate(). And what to do if the switch happened on weekend? A new copy won't start until Monday? Oh, yeah, we can put it on a timer! I've heard that you can shoot at sparrows with a cannon, slingshot would be a nice way to go.
These are still simple problems. Try to take this logic into account when working with multi-threaded DLL. Now here's where the fun begins. Well, we'll get stronger ))))
I have never heard of nuances such as those described in this thread, but I have never encountered problems with the problems described here.
if you want to transfer something to another copy of the indicator, you don't need to do it deinit - keep the transferred data up to date during all the indicator lifetime - for example in the main variables of the terminal, then no matter the reason of indicator unloading (change of TF, mum pulled the plug "so it won't hum when everyone sleeps", earthquake, change of earth magnetic poles and so on.etc.) the next launch of indicator (including copy at TF change) will get all necessary information from this magic data source (for unlucky cases of global scale it's possible to keep data on cloud disk).
Guys, there is no problem at all.
There is a problem: simultaneous existence of objects from different indicators. "Sorry, we have temporary technical problems" (but they will be resolved in a few seconds, when the old indicator DeInit happens)
A narrow field of vision. That's why you can't see. Broaden your horizons a bit. The first problems occur already when working with files, because it is not clear whether the previous indicator has managed to save data to the file or not yet. Some flags in the global variables of the terminal will have to be created. The new copy of the indicator will have to wait for the old copy to reset the accumulated data. By the way, the problem is that such synchronization is possible only in OnCalculate(). And what to do if the switch happened on weekend? A new copy won't start until Monday? Oh, yeah, we can put it on a timer! I've heard that you can shoot at sparrows with a cannon, slingshot would be a nice way to go.
These are still simple problems. Try to take this logic into account when working with multi-threaded DLL. Now here's where the fun begins. Well, we'll get stronger)))
I've already clearly written - keep the data you need for copying always up-to-date. You don't have to do it only during initing, you must always keep it up-to-date.
All other cases are contrived due to crankiness.
If there is a problem with running the same indicator at the same time, then create unique objects each time with a link to the TF and if there are already objects add 1 to the name.
No one has cited a single case where the problems are insurmountable due to the current way the terminal works with indicators. The problems are caused by incorrect work with indicators.
In general, many people don't seem to understand that there are 3 types of programs for a reason (the 4th one will be available soon).