Init() and DeInit() execution sequence - page 3

New comment
 
Aleksei Radchenko:


Try to update the terminal to version 1065. Previous versions had a reinitialisation error just by changing the timeframe. Might help :)

https://www.mql5.com/ru/forum/187690


I have terminal 5.00 b1571
 
You can save the variable values somewhere, in globals for example. after retranslation, you can read and restore the variables.
 
Andrey Dik:
You can save variable values somewhere, in globals for example. After you've translated them, you can read and restore the variables.


And then Deinit will finish its work and spoil everything. There is no sense in regular Init and Deinit if to make your own custom Init and Deinit.

I've encountered this problem too. (

 
Sergey Chalyshev:


And then Deinit will finish its work and ruin 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 completely agree (No sense in regular Init and Deinit)
 
Vasiliy Pushkaryov:


Maybe try assigning graphical objects a TF period as part of their name prefix,

and then apply something like this:


Thanks for the reply

Yeah had to do something like that, but it's a partial solution.

You can do the same with variables through a resource or files, but this is a separate additional resource, which could have been avoided by fixing MT5

Cluttering the code with extra side functions, checks, etc. (WITHOUT....)

 

I've always thought (it turns out in vain), that when I change TF, I first deinit on the old TF and then Init on the new one. This is a logical course of events. I relied on this logic when developing Expert Advisors and indicators. And now it turns out to be a real nonsense with events interrupting the sequence of events...
I sometimes noticed when working with charts and graphical objects that something was wrong and I had to switch TFs several times to see that everything was displayed correctly.


Now I have to look into the codes, where in deinites something changes and then inites also change back... and it turns out the sequence is the opposite!!! That's just awful logic. Who came up with this?

The first thing that comes to mind is that in my deinit the previous state (pressed/released buttons) is stored in the global variables and then the buttons are set according to the saved values in the inits. And it's the buttons that don't always reset correctly. This is the first thing I remembered, maybe I'll find something else... will be digging around tomorrow.


Thanks to the developers, they put a lot of work...

 

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.

 
fxsaber:

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 "unreadable" then we just wait for the semaphore to return (either via loops Sleep or OnTimer).


What is so complicated about such an implementation? To write it once in the library and that's it.

I didn't know that such a problem exists. I was hoping for the deinit-init sequence and not vice versa. When you know the problems, you may solve them. But it seems to me that it should be solved at the terminal logic level and not with crutches, which one now has to put in each program...
 
elibrarius:
I didn't know there was such a problem at all. I was hoping for a deiniti-init sequence and not the other way round. When you know the problems, you can solve them. But it seems to me that it should be solved at the level of terminal logic and not with crutches, which should be inserted into every program now...
It's not a crutch, it's a simple solution. The question is who implements it - developers or users. In both cases you should spend time and write it once. If users can do it, we wrote it and don't bother discussing the question any more. I just read the thread myself and a solution came to my mind right away. What is there to pore over? You can demand something for a long time, or you can write it quickly yourself.
 
fxsaber:
This is not a crutch, but a simple solution. The only question is who implements it - the developers or the users. In both cases you have to spend time and write it once. If users can do it, we wrote it and don't bother discussing the question any more. I just read the thread myself and a solution came to my mind right away. What is there to pore over? You can demand something for a long time, or you can write it quickly yourself.
If you multiply the number of small people, which - each by himself, again and again - will solve a common problem, then the wasted man-hours many times (in the limit, an infinite number of times ;-)) will 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"?
12345678910...28
New comment
Reason: