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
This sounds like nonsense. Indicator copy timers have nothing to do with each other.
500 years ago, the statement that the Earth is spherical sounded like nonsense to most people too.
OK, I'm going to redo this example for a timer now.
Ok, I'll now redo this example for the timer.
Where it is unambiguous.
Try this primitive example. You will understand the "uniqueness" when switching the TF.
In this example, an object with coordinates of current time and price is created in OnInit. In OnCalculate this object moves together with the price.
In OnDeinit it is simply (logically) deleted.
When switching the TF, it turns out that the object appears and then disappears.
Why does this happen?
Because sometimes OnDeinit of the old TF deletes what has already been created in the OnInit of the new TF. It is not a bug! What should the programmer who created this example think and did not read this branch?
Do you want to show that the EvenKillTimer in the old deinit state will affect the EventSetTimer in the new init?
I was wrong. My apologies. My mistake.
Indeed, the timer of the new TF turned out to be survivable, unkillableEventKillTimer of the old TF. :)
In your example, the graphical object is present in all TFs, you just need to zoom in to see it.
No, it isn't. It is removed sometimes by the Deunit of the old TF.
Indeed, the timer of the new TF turned out to be resilient, unkillable by the EventKillTimer of the old TF. :)
No, it's not. It is deleted sometimes by Deinit of the old TF.
To force updating of graphical objects, use ChartRedraw() command to redraw graph.
Add this to Init and Deinit:
ChartRedraw();
Add this to Init and Deinit:ChartRedraw();
Tried it. This does not change the situation, and can not change, if the object has already been removed,ChartRedraw() will not resurrect it.
I don't exclude, Sergey, that this "peculiarity" of ambiguity of execution sequence of OnInit of the new TF and OnDeinit of the old TF may depend on the hardware. Since different threads, different processors with different coprocessor architecture - it's all complicated and I'm not good at it. But the fact that this "feature" appears on my computer and on the computers of others, judging by this thread, is certain.
So, you want to say that you tried this example on your computer and when you switch TF you always see the object?
By the way, I noticed that if you increase the candlesticks to the maximum size, i.e. the screen has a minimum of bars, it is very difficult to make the object disappear. I had to switch the TF 30 times to remove the object (i.e. DeUnit was triggered later than Unit). Apparently this "peculiarity" is affected by the performance of the threads. This is as a hypothesis or a thought out loud.
Very glad my delusion turned out to be a delusion.
:) It wasn't a delusion, just a hypothesis.
Thanks for the hypothesis. Thanks to it andfxsaber I had a new round of awareness of what an indicator copy is. The timer simply belongs to that copy and dies along with it even when the TF changes. But objects live by themselves, even if they are created by a copy of the indicator, they only belong to the window. Now I understand that there is no point in writingEventKillTimer in the Deunit, anyway, the timer will die if the Deunit has already been called.
I.e. the whole problem is adding ONE line at the beginning of any indicator.
Library code