Init() and DeInit() execution sequence - page 4
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
In Deinit, write all data to globals. Set one of the globals as a semaphore viaGlobalVariableSetOnCondition.
In Init write that if the semaphore is in "data dumped" state we will read and work by setting the semaphore to "read all" state.
If the semaphore is "unintelligible" then we just wait for the semaphore (either through a looped Sleep or OnTimer).
If there is no semaphore at all it means that we start up for the first time and count everything and at the same time we create a semaphore for the non-future change of the TF.
What is so complicated about such an implementation? To prescribe once with a library and that's it.
If Sleep worked in indicators, it would be easier. Sleep does not work in indicators.
If you multiply the number of small people, who - each by himself, over and over again - will solve a common problem, then the wasted man-hours many times (in the limit, an infinite number of times ;-)) exceed the time needed for any variant of editing in the terminal itself. Even the presence of a hypothetical library does not guarantee that everyone will be aware of its existence and need to use it. In general, it is not clear why to make and leave such "rake"?
So it's not a rake, it's logical behaviour when the new copy of the indicator doesn't know about the old one. This is logical!
But ONE THOUSANDS of people want additional functionality so that the copy does know! So what prevents these units from writing a solution once and using it?
Why pretend to care about other people. Who really needs it, will look for a solution first. And if they don't - they will try to write one. A centralized codebase serves precisely that purpose.
If Sleep worked in the indicators, it would be easier. Sleep does not work in indicators.
So it's not a rake, it's logical behaviour when the new copy of the indicator doesn't know about the old one. This is logical!
But ONE THOUSANDS of people want additional functionality so that the copy does know! So what prevents these units from writing a solution once and using it?
Why pretend to care about other people. Who really needs it, will look for a solution first. And if they don't - they will try to write one. A centralised kodobase serves precisely that purpose.
No, it's not that simple. Indicators are inside another entity - a chart/chart, and are subordinate to it (I am aware of their complex one-to-many relationship, but it doesn't change the essence). A chart has its own life cycle, which includes some kind of internal init and deinit events, which are the boundaries for the life cycle of the indicators. In other words, an indicator cannot outlive its chart. The chart's deinit must wait for the deinit or timeout of deinit of all indicators. Only then the chart init for the new timeframe can be started, and from it the inits of attached indicators can be called.
A rake is, by definition, something that can be stepped on. Already stepped on. Good software does not allow for rake in principle.
So it's not a rake, it's logical behaviour when the new copy of the indicator doesn't know about the old one. This is logical!
But ONE THOUSANDS of people want additional functionality so that the copy does know! So what prevents these units from writing a solution once and using it?
Why pretend to care about other people. Who really needs it, will look for a solution first. And if they don't - they will try to write one. A centralized kodobase serves precisely the same purpose.
How is it that you do not know when you switch timeframes and enter the input parameters again?
And then Deinit will finish its work and spoil everything. There is no sense in regular Init and Deinit if you make your own custom Init and Deinit.
I've encountered this problem too. (
I' ve already told you everything, but I'll add more of my own.
The peculiarity of all programs for MT is that they work based on events. The OnInit and OnDeinit work quite logically and appropriately according to the event model.
But there is one strange nuance of input-variables behavior: all basic indicators, including internal terminal ones and those that are included into standard delivery - each time they are started with the same input-parameters that have been called since the previous start. It is very convenient. But there is no such a thing for custom indicators and all Expert Advisors and scripts including standard ones, this is some inconvenience(wish to MQ: add the same behaviour for input variables as for standard indicators).
And what concerns work with Init and Deinit, so, personally, I never laid down on reasons of deinitialization of programs when working with global variables of program, I always build logic under the specific idea of the program. For example, very often it is necessary to save global variables of a program after deinitialization of an EA (the reasons can be different, for example the same disconnect causes OnDeinit and the subsequent OnInit), so why should I recalculate everything and create new indicator handles, etc.?
That's why, as I wrote before and fxsaber, if you need to save global variables of a program in some cases - you can do it in global variables of the terminal using the appropriate flags.
In MQL not everything is smooth, unfortunately, but the work of OnInit and Ondeinit is logical and understandable, so it's a waste of time).
What do you mean you don't know, when you switch timeframes do you re-enter the input parameters?
But the workings of OnInit and Ondeinit are logical and understandable, so there's no need to make a big deal out of it.)
Please explain the logic of the sequence of OnInit and OnDeinit in the indicator when you switch the timeframe. I would be very grateful. And I think I am not the only one.
Please explain the logic of the sequence of OnInit and OnDeinit operations in the indicator when you switch the timeframe. I would be very grateful to you. And I think I am not the only one.
Mr Slava said it clearly.
A copy of the indicator is created and the old one is unloaded after some time.
If we want to save global variables of the program, we should take care of it already beforehand at the moment of calling OnInit (global variables of the client terminal are good for this purpose).
And indicator buffers will be recalculated anyway, because the bars (candlesticks) have changed, apparently, this is why it happens this way (the copy will be started and the previous indicator instance will be finished by the terminal).
If the indicator developer sees the problem in working with graphical objects, then at the start of the indicator it is necessary to tie the names of graphical objects to the name of TF, then the new copy of the indicator will create new objects, and the previous copy of the indicator will clean up the old ones.
No problem at all.
Forum on trading, automated trading systems and trading strategies testing
Init() and DeInit() execution sequence
Slawa, 2017.04.07 15:31
What kind of logic does it mess up?
When you change timeframe, a new copy of the indicator is created, which knows nothing about the previous copy. For a while (a very short time) both copies of the indicator exist in parallel. Then the previous copy is unloaded.
Read documentation https://www.mql5.com/ru/docs/runtime/running
Mr Slava said it clearly.
A copy of the indicator is created and the old one is unloaded after some time.
If we want to save global variables of the program, we should take care of it already beforehand at the moment of calling OnInit (global variables of the client terminal are good for this purpose).
And indicator buffers will be recalculated anyway, because the bars (candlesticks) have changed, apparently, this is why it happens this way (the copy will be started and the previous indicator instance will be finished by the terminal).
If the indicator developer sees the problem in working with graphical objects, then when you start the indicator, you should tie the names of graphical objects to the name of TF, then the new copy of the indicator will create new objects, and the previous copy of the indicator will clean up its data.
There is no problem.
Yes, it's understandable. I was asking about the logic of the sequence of execution. The thing is, there is no such logic. Sometimes OnDeinit is executed first (as it should be according to the common man's logic), and sometimes OnInit is executed first.
I understand that the answer lies in the remark"For a certain period of time (a very short time) both copies of the indicator exist in parallel". But this does not make the question any clearer.