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

New comment
 
Ihor Herasko:


Why would they be slow? Unless the indicator is poorly written. A well-written DeInit indicator takes quite little time. Moreover, TF switching is not such a frequent operation. In some especially serious cases (for "wrong" indicators) you can wait a second or two when changing TFs.

Therefore, the argument about braking during TF switching is more than dubious. Besides, when we switch to the TF that has not been built yet, we also encounter quite an appreciable time delay. And no one cries about terminal's brakes.

Indicators are different. There are also slow ones. And not all of them are their own and in source code.

I am amused by a couple of seconds. I feel tens of milliseconds in the interface, I feel discomfort at once.

And, most importantly, there is no answer to my question:
In what situations, except straightforward work with graphical objects (without TF name in the title), is the DeInit - Init sequence important?

 
Andrey Khatimlianskii:

Indicators come in all shapes and sizes. Braked ones too. And not all of them are their own and in source code.

A couple of seconds is funny. You can feel tens of milliseconds in the interface, there is discomfort at once.

And, most importantly, there is no answer to my question:
In what situations, other than straightforward work with graphical objects (without TF name in the name), is the DeInit - Init sequence important?


I don't usually use global variables, but sometimes it happens.

When working with global variables we get mess. When deleting the indicator from the chart you need to clean up after yourself and delete the global variables. In what place of the indicator you will delete the global variables? Probably, it should be deleted in Deinite, there is no other place. So, when you change timeframe and create new variables, Deinite comes and erases everything. It turns out that Global Variables cannot be used in indicators.

 
Sergey Chalyshev:


I usually don't use global variables, but sometimes it happens.

When working with global variables, you get choppy. When you remove the indicator from the chart, you need to clean up after yourself and remove the global variables. In what place of the indicator will you delete the global variables? Probably, it should be deleted in Deinite, there is no other place. So, when you change timeframe and create new variables, Deinite comes and erases everything. It turns out that Global Variables cannot be used in indicators.

Sergiy, do you have a real example that is not taken out of thin air? I can also think of such an example, but I have not faced any problems in practice.

Note: Global variables can also be named depending on TF.

 
Andrey Khatimlianskii:

Indicators come in all shapes and sizes. Braked ones too. And not all of them are their own and in source code.

A couple of seconds is funny. The interface feels tens of milliseconds, discomfort immediately appears.

And, most importantly, there is no answer to my question:
In what situations, apart from straightforward work with graphical objects (without a TF name in the title), is the DeInit - Init sequence important?

On page 3 I gave a practical example:
The first thing that comes to mind is that in my deinit the previous state (buttons pressed/released) 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, I may find something else...
 
elibrarius:
on page 3 I gave a practical example:

memorise in the terminal head each time the relevant variables are changed, not when ini/deinit.
 
Andrey Dik:

remember in the main terminal each time the corresponding variables are changed, not when ini/deinit.

I'll remember)
And also remember, that in current implementation nothing can be done in Deinit which then must be used (neither in global variables or writing to files)...

essentially useless finci has become, with such a broken sequence.

I will remember (good that I stumbled on this thread by accident), but other programmers (who won't look here) will use natural logical consequence and use Deinit hoping it will work, and then init will run on a new TF.

 
elibrarius:

I'll remember)
Also remember that the current implementation of the terminal doesn't allow to do anything in Deinit that should be used later (neither in global variables, nor in files)...

essentially a useless finkzi, with such a broken sequence

Just understand that there is also other logic. The logic of MT developers in particular. According to this, other logic everything looks quite logical. Hence the conclusion: adjust to this logic and do not try to change the minds of people who are probably more experienced than you in it. It is useless... No one will agree to change the established logic for the sake of one indicator.
 
Well, I'm not the first to have this problem, so it's not for one indicator. I've already done it all for myself, but others may be stepping on this rake too. Isn't it better to simply remove the rake so that no one else steps on it?
 
Alexey Viktorov:
Just understand that there is also other logic. The logic of the MT developers in particular. According to this, other logic, everything looks quite logical. Hence the conclusion: adjust to this logic and do not try to change the minds of people who are probably more experienced than you in this. It is useless... No one will agree to change the established logic for the sake of one indicator.


If it was not about finance, perhaps there would not have been such a discussion.

And since a trading advisor depends on one indicator or the other, it will simply stop working properly because of a simple switch of the TF. That's what's most stressful.

So how can you trust him with your finances?

We may be at odds with the MT developers on this one.
 
Andrey Khatimlianskii:

Imagine how slow the charts would be if before changing the TF the terminal waited for the unloading of all indicators from the old TF and only then built and initialized the new one.

In what situations, apart from the straightforward work with graphical objects (without the name of TF in the name), is the DeInit - Init sequence important?

You guys are all confusing a lot of different things. Let's agree on at least two requirements for the terminal as critical software:

- it must work predictably, strictly following the same logic (even with multi-threading);

- it must work quickly.

(it's not important whether the copy of the indicator knows about other copies, but it's important that the global data, assigned for storage to the terminal, should be consistent - this is the concern of the terminal, not of each indicator developer)

Further there is a question - how to implement it. Now it is implemented taking requirement 2 into account. I propose to implement it considering requirement 1, without affecting requirement 2.

There will be no noticeable slowdowns, if we pay attention to the fact that the events of init/deinit chart and init/deinit of indicator are different things. The chart will immediately show the main new chart, but for legacy indicators the OnInit event will be queued after the processing of the previous OnDeinit. The events are queued in the terminal anyway.

If MQ wishes, can send me on his terms NDA charts of classes and sequences, I will correct them ;-).

12345678910111213...28
New comment