Init() and DeInit() execution sequence - page 12
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
That's it, the lamentations have started...
What you're asking for is exactly what regular desktop applications don't have.
What isn't in the app? Synchronization? )))
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 or speed of execution.
1. What-what isn't in the apps? Synchronisation? )))
2) You are making unscientific reasoning without facts. In MT4, indicators operate with successive OnInit() and DeInit(). There is a disadvantage - all indicators work in a single thread. It can be solved by properly writing the indicator, which is also required in MT5. Although, MT5 hasn't gone away from it - anyway, indicators of one chart continue to work in one thread.1. what synchronisation are you talking about!
2. In MT4, as part of the execution of the indicator code, init is first executed and then deinit, what else do you need!!! It's the same in MT5.
Several people already asked me to give a specific example of a task that is problematic to perform within the indicator execution paradigm in MT5. Will there be an example or not, a clear example, not sucked out of thin air?
1. What synchronisation are you talking about?!
About inter-threading. Until one thread completes (the one given the command to terminate), the other thread doesn't start. Or, if it all happens in one thread, it's even simpler: terminate all programs associated with the "old" TF and only then start programs on the "new" TF.
2. In MT4, as part of the execution of the indicator code, init is first executed and then deinit, what else do you need?! The same is in MT5.
Right. This is exactly the case in MT4. But it's not so in MT5. And this is what the subject is about.
Several people already asked me to give a specific example of a task, that is problematic to perform within the indicator execution paradigm in MT5. Will there be an example or not, a clear example, not sucked out of thin air?
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?
OS cares that TC doesn't interfere with other TC's and what they do there in RAM, exchange files or whatever else is their business.
"I think so!" (c) Mimino, 1977.
What does Total Commander have to do with it? It's just a low-level utility in the sense that it operates directly with the system resources. In the case of MQL, the task of MT platform is to free the application programmer from system cares such as synchronization - the platform can provide this more effectively and in one fell swoop for all. MQL programmers must think about the analysis of quotes and trading strategies. This is the purpose of MT.
What does this have to do with the exchange of files and data? Consider the logic of work in the context of an MQL program. It simply attempts to use the events OnInit/OnDeinit according to their intended purpose - to correctly start from a certain state and correctly terminate itself with saving the state. If they are not suitable for this purpose, then, as already noted, what are they for? Judging by the arguments of defenders - so that we could dance around inside and find out what other copies were executed before and after, and from which timeframe and to which one they have switched? This has exactly the opposite effect of what MQ wanted to achieve - that one copy knows nothing about the other.
In order for one copy to know nothing and not have to find out, and still work without side-effects, the kernel needs to know about all copies - both those that are shut down and those that are starting up - and provide graceful handling of init/deinit events for them in a standard queue metaphor. The terminal tracks all copies anyway, and uses the event queue, but for some reason init/deinit breaks the event logic.
In order forone copy to know nothing and not have to figure it out, and still work without side-effects, the kernel needs to be aware of all copies - both those that are terminated and those that are started - and provide graceful init/deinit event handling for them in the standard queue metaphor. The terminal keeps track of all copies and uses the event queue, but for some reason init/deinit breaks the event logic.
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?
Andrey, I don't like global terminal variables. I've experimented with them (a long time ago) and I was very disappointed by their speed and synchronization difficulties. To avoid unsupportedness I'll try to write an example (a bit later) that demonstrates their speed. Perhaps something has changed and I'm wrong. But another thing that I don't like about global variables is that they have their own life of their own and they are absolutely public. Everyone can check them by pressing F3 and delete them. When there are several of them, that's half the trouble, but if everyone starts using them, I personally get a feeling of a mess on my desk.
About passing the arrays. Yes, I agree, it's not necessary very often. But here is a specific example - my indicator. Its internal operation does not depend on the selected TF, because during initialization it downloads all (almost all) TF and creates its own general array (something like a logarithmic array of quotes) and performs some more voluminous calculations of index arrays based on it. When changing TFs, doing one and the same amount of work each time is not at all rational - there will be delays when switching TFs. I also have in my head algorithms for pattern recognition, which I will implement, so there initialization calculations can take up to several seconds, and I would like it to happen only once and forget about it.
In order for one copy to know nothing and not have to figure it out, and still work without side-effects, the kernel needs to know about all copies - both those that are terminated and those that are started - and provide graceful init/deinit event handling for them in the standard queue metaphor. The terminal tracks all copies anyway, and uses the event queue, but for some reason init/deinit breaks the event logic.
And now imagine that there is not one single event queue, but rather a queue for each character-period. As many symbol-periods, so many queues.
Now suggest the order in which the queues are handled.
And now imagine that there is not one single event queue, but rather a queue for each symbol-period. As many symbol-periods as there are queues.
Now suggest the order in which the queues are handled.
1. about inter-threading. Until one thread completes (the one given the command to terminate), the other thread doesn't start. Or, if all this happens in one thread, it is even simpler: we terminate execution of all programs connected with "old" TF and only after that we start programs on "new" TF.
2. Right. It's exactly the same in MT4. But it's not so in MT5. That's what the subject is about.
3. I gave working with graphical objects, a beauty is born: one indicator still exists and hasn't cleaned up, while the second one is drawing over these objects. That is how we will explain to the user: "When switching the TF you will observe short-term disturbances". )))1) It should be done as I wrote earlier: accumulated database should be periodically saved to a file or other storage, no problem - open file, write, close. You need to do this every time you update this data or periodically, not ininit and deinit. (You save work periodically when you write a program, write an article). And it is impossible to insure against failure of writing to file, sometimes for insurance in critically important situations they do the following: they write updated information to a new file, after successful writing they delete the old one, and change the name of the new file as it was in the old one.
2) I already explained it. Each indicator must work with its own graphical objects. Of course, we have to check the existence of the objects and if they already exist, we have to add 1 to the object name.
3) Well, you have already written that it is solvable.
And these are not problems at all. This is the normal operation of programmes - creation of unique objects, periodic saving of accumulated information, cleaning up after completion.
1. these are your wishes. But you said you wanted the way desktop apps work, so the way you want desktop apps don't work.
What do you call desktop applications? It feels like MT5 is not a desktop application.
2. Don't make up stories. The sequence of oninit and ondeinit is the same in MT4 and MT5. There is no such thing as a program starting with deinit.
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) OK, let's analyse the examples:
1) To do as I wrote earlier: accumulated database should be periodically saved to file or other storage, no problem - opened file, wrote, closed. You need to do this every time you update this data or periodically, not ininit and deinit. (You save work periodically when you write a program, write an article). And it is impossible to insure against failure of writing to file, sometimes for insurance in critically important situations they do the following: they write updated information to a new file, after successful writing they delete the old one, and change the name of the new file as it was in the old one.
Try to update the same file several times per second and share your feelings.
2) I already explained it. Each indicator must work with its own graphical objects. Of course, we have to check the existence of the objects and if they already exist, we have to add 1 to the object name.
What does this have to do with adding 1 to the name? It is 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.
3) Well, you have already written that it is solvable.
This is not a problem at all. This is normal program operation - creation of unique objects, periodic saving of the accumulated information, cleaning up after completion.