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

New comment
 
fxsaber:
The example you reworked was not perfectly suited to the problem at hand. You can show another example which will not have a solution through UninitializeReason.

That's it, I'm ending this dialogue. What is the point of discussing ways of scratching your ear? If there is no other solution, you can use your code, but universality is not always the ideal solution.

For example, to cut out 1 raspberry bush, no one would think of calling in a logging crew. So your code is comparable to a lumberjack crew to cut one raspberry bush.

Regards Alexei.

 
I don't understand, if old DeInit and new OnInit are executed in different threads, what's the problem with OnInit just waiting for DeInit to occur and finish. Use a global variable as a semaphore.
 
Aleksei Radchenko:
I don't understand, if old DeInit and new OnInit are executed in different threads, what's the problem with OnInit just waiting for DeInit to occur and finish. Use a global variable as a semaphore.
On a single chart all the indicators only run on one thread.
 
Alexey Viktorov:

What's the point of using a primitive example of a two-timer?

Use an example of Virtually correct code instead.

Alexey, this example was created so that even a Loser could understand it. That's why I wrote that it's primitive. Sorry, it wasn't designed for straight A's.

Saw a little dog barking at passing trucks this morning. She sends her love.

 
Nikolai Semko:

Alexei, this example was created so that even the underachievers could understand it. That's why I wrote that it was primitive. Sorry, it wasn't designed for straight A's.

Saw a dog barking at passing trucks this morning. She sends her love.

Were you barking with her?

What can be understood from the example where there is no check of object presence before its creation? Claims against the developers that they have not made it possible to write any way, with gross errors? I will write any way I want and developers must provide me with all conditions for that. Developers have to provide for all the possible mistakes I may make in the future. Is that it? Don't suck the problem out of where it doesn't exist.

 
Alexey Viktorov:

What can be understood from the example where there is no check for an object before it is created? Claims against the developers that they didn't make it possible to write as they please, with gross errors?


Alexey, you seem to be completely out of the loop. Read primary sources, please.
Here's a quote:"If an object has been created before, an attempt is made to change its coordinates. "

I understand that it's good form in large works to put checks of various kinds. But in this case this check is meaningless. Because if there is no object, ObjectCreate will create it, and if there is, it will simply change its coordinates. In this very primitive example, the goal was to show the fact of deleting an object by Deunit of old TF, which it demonstrates perfectly.
Your "hit-and-run" is about nothing. Most likely just an attempt to draw attention to yourself.
And if you want superfluous lines of code, devoid of any sense, in order to train your fingers, I recommend an excellent resource "Keyboard Solo".

 
Alexey Viktorov:

Were you jumping in with her?

What can you understand from the example where there is no check for an object before it is created? Claims against the developers that they didn't make it possible to write whatever you want with crude mistakes? I will write any way I want and developers must provide me with all conditions for that. Developers have to provide for all the possible mistakes I may make in the future. Is that it? Don't suck the problem out of where it doesn't exist.


What's so terrible about trying to create an existing object? Will it disappear?
 
Dmitry Fedoseev:

What's so terrible that would happen if we try to create an existing object? Will it disappear?

Dimitri you seem to me to be an educated programmer. You have not been taught the rules of etiquette in programming?

For the rest you can write like in old mql4 with the possibility of array overruns and other assumptions. You get an error in response... Well, flag it back... let's go on, we don't have time... And then we run into a problem that is not worth a damn in a stricter language and start to complain to developers...

Christ is risen.

 
Nikolai Semko:


... The purpose of this very primitive example was to show the fact that Deunit removed the object of the old TF, which it demonstrates perfectly. ...

The fact of failure is shown in the counter-example. You don't have to suck the problem out of where it doesn't exist. Put a check on the reason for deinitialization and the object is not deleted, it just changes its coordinates.
 
Alexey Viktorov:
The fact of failure is shown in the response example. It is not necessary to suck the problem out of where it is not present. You check the reason for deinitialization and the object is not deleted, it just changes its coordinates.
//Часть твоего кода:
void OnDeinit(const int reason)
  {
   if(UninitializeReason() != REASON_CHARTCHANGE)      // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред! 
                                                       // И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная  reason?
    {
     ObjectDelete(0,"InitDeinit");
     ChartRedraw(0);                                   // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так. 
     Print(__FUNCTION__, "  InitDeinit удалён");       // А где ж твоя любимая проверка, вдруг не удален.
    }
  }

My example was created to show the problem of the ambiguous sequence of the Unit of the new TF and the Unit of the old TF, not as a solution.

You just bypassed the problem, not solved it.
In my example, it is just important that in the Unit of the old TF the object is deleted in any case, including when the TF is changed, and in the Unit of the new object it is created again.

If the sequence is first Deunit of the old TF, then Unit of the new TF, as it should logically be. Then the object is deleted and then created again.

If the sequence is first the Unit of the new TF and then the Deunit of the old TF, then the object is simply modified when you try to create it in the Unit, because it is not yet deleted. And then it is deleted by the Deunit of the old TF. This is the bug.

That was the point of this example - to show what any programmer who has not read this branch and is unaware of this "feature" may encounter.
This example was not meant to be a solution. As variants of the solution are presented here and here. I think I will also add a solution later, but without using global variables and files of the terminal and for this solution to work even if several identical indicators are set in one window. Have you tried to solve this problem? Or you are only capable of finding errors in other people's code, especially when they are not there.

Don't be stupid anymore!

1...171819202122232425262728
New comment