Init()和DeInit()执行顺序 - 页 19

[Nikolai Semko]

Slawa:

无解是指 "还不知道如何解决"，而不是 "不会"。

而对于用户事件，则完全没有问题。

吁...你吓到我了 :)

[Stanislav Korotky]

fxsaber:

服务或在一个图表上运行多个EA的能力怎么能不完全涵盖所讨论的问题？

好吧，问题仍将存在。仅仅因为会有一个新的MQL-程序类型，它并不能解决其他类型的MQL-程序的问题。好的软件不允许用户犯错。在帮助中写一个关于行为的不确定性的短语，当然更容易。要靠溺水的人去救他们。

[fxsaber]

Stanislav Korotky:
要靠溺水的人去救他们。

当然，人们可以继续感叹，当救生绳被抛出时，岩石仍然没有为溺水者的获救作出贡献。

[Alexey Viktorov]

elibrarius:
我建议删除125帖以后的所有内容，因为这与改变TF时的deinit和init队列的建设性讨论无关。

最好是删除整个主题。并像一个不愉快的梦一样忘记它。

[Alexey Viktorov]

Dmitry Fedoseev:

有一个指标确实是先有初始值，然后再有脱敏值。但是当时间框架被切换时，第二个指标实例被创建，它的init可能比前一个（未启动的）实例的deinit提前执行。

最明显的例子是--切换时间框架时保存用户参数--我们在deinit中保存参数，在init中读取它们。如果新实例的init在前一个实例的deinit之前被触发，参数将不会被保存。

实际上，被删除的实例的deinit大多在新实例的init之前触发，但是如果时间框架切换得非常快，或者数据被加载，那么就会出现故障。

迪米特里，驾驶汽车时，当你已经到达时，你是否要看一下后视镜？或者你必须定期在指标中保存所需的参数。这就像在看后视镜。

[Stanislav Korotky]

fxsaber:
当然，你可以继续抱怨，当救生圈被抛出时，石头仍然没有为拯救溺水者做出贡献。

耙子还在。这是最主要的事情。(在这个比喻中，在船厂按需发放一圈，人们随意地、意外地溺水）。

如果旧的芯片不全，新的芯片也会有问题。方法不会改变。

总而言之，我已经陈述了一切，我认为是比较合理和符合逻辑的。如果有人在罐子里，我也帮不上忙。

[fxsaber]

Stanislav Korotky:

如果旧的功能不全，新的功能也会不全。方法不会改变。

这里的问题是他们是不能还是不愿意？看起来他们不能。

[TheXpert]

Slawa:

换句话说，当改变图表的 符号周期时，指标的OnInit和OnDeinit的执行顺序不应该困扰任何人。

OnInit启动定时器，onDeinit删除它。由于错误的队列，没有人知道什么。

令人不快的错误，被开发者公然忽视了

[fxsaber]

Комбинатор:

Init启动计时器，deinit删除它。由于排队错误，不知道发生了什么事。

一个被开发者公然忽视的讨厌的错误

队列是毫不含糊的。

[TheXpert]

fxsaber:
该命令是毫不含糊的。

当你改变f。

如果指标的缓冲区里仍有来自旧TF的垃圾，也许定时器也会受到影响。