Init() and DeInit() execution sequence - page 11
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
Isn't it a pity to waste your time on such useless bickering about such a trifle?
Actually, it's even more important just to be aware of this peculiarity.
I have clearly written - keep the data needed to be transferred to the copy always up to date, you don't need to do it only when initing, always keep it up to date.
Where this data should be up to date? An example, please. I don't think you can do better than a file. So, just with the file is a huge problem. Or do you think that updating a file every second is an excellent practice?
All other cases are contrived due to crankiness.
So, "temporary disturbance on blue screens" is also the fault of the one who is writing the indicator? This is exactly the example that no one has yet said how to get around. And there is no way around it.
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 occur due to the improper handling of indicators.
I have already given several examples. But you simply dismiss them, or in other words, close your eyes to the problems.
In general, many people don't seem to understand that there are 3 types of programs for a reason (the 4th one will come soon).
Yes, for a reason. Because of an elementary human weakness - to stop halfway. There must be 1 type of program in a platform. No more and no less. Appearance of the 4th type is a deepening of self-defeat.With that kind of attitude towards developers, it's strange to hear you expecting developers to solve your problem.
And if even I, an ardent fighter for all sorts of improvements and simplifications for the platform don't see a problem, people who like to stop halfway through won't see a problem.
Isn't it a pity to waste your time on such useless bickering about such trivialities?
With that kind of attitude to developers, it is strange to hear from you that you expect developers to solve your problem.
I have a normal attitude towards platform developers )) Human weakness is our common problem, not the problem of its individual representatives.
Although you and I have really diverged from the topic of types of programs. You should have a separate thread for that. But I don't see much sense in it, as it will be purely academic without even a hint of practical application.
The meaning of what I'm talking about is the usual logic of program execution. This logic was in MT4, and in a good way it must be transferred to MT5. In fact, it's not a disadvantage of MT4. In this case, it is its advantage over MT5. So, if you want to develop MT5 and quickly forget about MT4, why not take the best from MT4? Well, we have to fix the shortcomings and, at most, to improve the advantages. But to introduce new drawbacks...
So that's it!?
I've been experimenting and using this reason code(REASON_CHARTCHANGE) to the fullest extent. What's the use if all variables are set to their original state again and OnDeinit can be executed after OnInit of the new TF
Reasons for deinitialisation
Expert Advisor deinitialization reason codes returned by UninitializeReason(). Can have any of the following values:
.........
Indicators only accept code 1(REASON_REMOVE) and code 2(REASON_RECOMPILE) for now.
Reasons for deinitialisation
Expert Advisor deinitialization reason codes returned by UninitializeReason(). Can have any of the following values:
.........
Indicators only accept code 1(REASON_REMOVE) and code 2(REASON_RECOMPILE) for now.
Reasons for deinitialisation
Expert Advisor deinitialisation reason codes returned by UninitializeReason(). Can have any of the following values:
.........
Indicators only accept code 1(REASON_REMOVE) and code 2(REASON_RECOMPILE) for now.
This is obsolete information. After numerous requests, we have started to send other reasons to the indicators
There were a lot of discussions too. It is strange that nobody remembered about the different copies of the indicators
I have a normal attitude towards platform developers )) Human frailty is our common problem, not the problem of its individual representatives.
Although you and I have indeed strayed from the subject of types of programmes. We should have started a separate branch for this. But I do not see much sense in it, because it will be purely academic, without even a hint of practical implementation.
The meaning of what I'm talking about is the usual logic of program execution. This logic was in MT4, and in a good way it must be transferred to MT5. In fact, it's not a disadvantage of MT4. In this case, it is its advantage over MT5. So, if you want to develop MT5 and quickly forget about MT4, why not take the best from MT4? Well, we have to fix the shortcomings and, at most, to improve the advantages. But to introduce new drawbacks...
That's it, we`re complaining...
You are asking for exactly what is not available in normal desktop applications. If the developers didn't do all these features that are already "out of the box", the writers of MQL programs would constantly face all the charms of desktop development, whether it's security issues or speed of execution.Very questionable question about nothing complicated. Try to really try to repeat by example of a simple wristwatch what I have implemented in this product. In the wristwheel you change the period with your mouse and then, when you change TF, the changes should be saved. 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.
What is the problem with storing the period in a main variable?
Why would it be necessary to transfer an array of data between successive runs of the indicator on different TFs?