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

新评论
 
Slawa:

如果在一个符号内有一个时间框架的变化，那么初始化和非初始化的顺序原则上是可以预测的。下载最新的Build 1580 - 我们在那里纠正了一些事情，现在指标是最后被移除的，所以应该不会有过早的脱位。

我不明白。请澄清一下。在init之后保证Deinit？
 
Andrey Khatimlianskii:

指标有各种形状和大小。刹车的也是。而且，并不是所有的都是自己的和源代码的。

几秒钟的时间很有趣。界面感觉有几十毫秒，不适感立即出现。


不要把它扭曲了。这不是接口的问题，而是瞬态的问题--TF切换。在一个空白的图表上，TF的切换是否需要无限长的时间？不，那么指标与此无关。



而最重要的是，我的问题没有答案。
除了与图形对象的直接工作（名称中没有TF名称）外，在什么情况下，DeInit - Init序列是重要的？


几乎在所有情况下。当然，除非我们处理的是MAshek类型的玩具和类似的基元。

  1. 写入文件。在断开指示器时，需要将积累的信息保存在一个文件中。因为不可能一直保持文件的开放。存在崩溃和丢失所有记录到文件中的信息的风险。
  2. 在处理图形对象 时。这是一种真正的美：一个指标仍然存在，还没有清理，而第二个指标正在这些物体上画图。这就是我们将如何向用户解释："当切换TF时，你将观察到短期干扰"。)))
  3. 与DLL一起工作。当Deinit DLL必须中断它所创建的所有线程。之后的下一个指标副本为自己重新创建它们。现在我们得到的是，新的指标副本将试图创建所有这些线程，它将被拒绝，因为它们仍在运行。新的指标将产生一个错误信息，不会工作。只是因为TF的切换。是的，这个问题是可以解决的。

同意。除第二个问题外，其他问题都是可以解决的，只要你了解这些问题。也就是说，我们现在必须把所有的逻辑塞进OnCalculate中，而Init和DeInit不应该被使用。但那时我们需要它们做什么呢？

总之，我们现在不是在讨论跨平台的问题。事实证明，MT4和MT5对Init和DeInit有不同的方法。

 
nmaratr:


如果不是关于财务，也许就不会有这样的讨论。

由于交易顾问依赖于一个或另一个指标，它将因为TF的简单切换而简单地停止正常工作。这是最有压力的事情。

那么，你怎么能把你的财务委托给它呢？

在这个问题上，我们可能与MT的开发者有分歧。

有很多选择来解决这个问题。而且几乎所有的人都在这个话题中表达过。

1.如果指标是用专家顾问编写的，专家顾问的编写方式应使其不受图表周期变化的影响。因此，该指标将不会被重新初始化。

2.如果你必须在deinit中删除图形对象或改变图表的设计，那么请检查deinitialisation的原因。

3.如果指标需要保存一些参数，那么，正如这里所说的，不要在脱机时保存这些数据，而是在准备或改变这些数据时保存。

4）在两堆垃圾中，总是选择臭味较小的那一堆。因此，当在所有指标所依赖的速度和在多个指标中保存一些数据的复杂性之间进行选择时，我选择速度。

 
Stanislav Korotky:
我不明白。请澄清一下。在init之后，deinit是否会被保证？

如果时间框架切换下降，首先在较低的（新）时间框架上OnInit，然后在较高的（旧）时间框架上OnDeinit。

如果开关是往上的，那么反之亦然。首先在较低的（旧）时间框架上OnDeinit，然后在较高的（新）时间框架上OnInit。

在这里我们应该记住，缓存的处理是从最低的时间段到最高的时间段。

 
Slawa:

下载最新的Build 1580 - 我们在那里修复了一些东西，现在指标是最后被移除的，所以应该不会有任何过早的脱位。


:() 哦，伙计，这是 "好消息"。现在我可能不得不在一些程序中重写代码，因为它是为 "反过来 "设计的--先是Deunit，然后是Unit。
说实话，这是个奇怪的逻辑。这意味着新旧指标副本将毫不含糊地在一起生活一段时间，直到该单元首先在新的指标副本中执行，然后在旧的指标副本中执行Deunit。那时，没有可能通过Deunit通知新副本的一些信息。这显然是一个烂摊子。因为单位通常比单元要繁琐得多。为什么会有如此奇怪的执行顺序！？那么这个话题就会一次又一次地被重新提起。但如果指标中的程序员有可能创建一些在改变TF时不被重新初始化的变量，那么让我们来处理这个OnInit和OnDeinit的序列。我已经写过好几次了（1 和2）。我同意开发者的逻辑，出于安全考虑，指针和引用对程序员来说并不奢侈，但如果你为指标的所有副本创建一个特殊类型的共享变量机制，我们将不得不为指标的所有副本创建相同的机制。指标是一样的，指标属性被储存在 "某个地方"。
 
Slawa:

如果时间框架切换下降，首先在较低的（新）时间框架上OnInit，然后在较高的（旧）时间框架上OnDeinit。

如果开关是往上的，那么反之亦然。首先在较低的（旧）时间框架上OnDeinit，然后在较高的（新）时间框架上OnInit。

在这里我们应该记住，缓存的处理是由低到高的。

这就更令人困惑了。

毕竟，如果该指标不是由作者本人使用，那么他可以随心所欲地切换，而不需要等待init和deinit？那会发生什么呢？如果在deinit中，对于开关的一个变体，有必要做一些动作，那么不管是为开关的一个方向还是为两个方向写，都没有任何区别。但他们为 "重 "指标增加了刹车。

 
Alexey Viktorov:

这就更令人困惑了。

毕竟，如果该指标不是由作者本人使用，那么他可以随心所欲地切换，而不需要等待init和deinit？那会发生什么呢？如果在deinit中，对于开关的一个变体，有必要进行一些操作，那么，如果它是为开关的一个方向或两个方向写的，那就没有任何区别。但他们为 "重 "指标增加了刹车。

在哪里加了刹车？相比之下，他们增加了什么？

请用代码支持你的陈述，这样，每个人都可以重现它。

再一次。由于指标的另一个副本是在符号周期变化时创建的，所以新符号周期的OnInit和旧符号周期的OnDeinit的顺序是未定义的。

 
Slawa:

在哪里加了刹车？与之相比，你增加了什么？

请善意地用代码来支持你的主张，以便每个人都能重现。

再一次。由于在改变符号周期时创建了指标的 另一个副本，所以在新的符号周期上执行OnInit和在旧的符号周期上执行OnDeinit的顺序是未定义的。

在这个信息中

Slawa:

如果切换时间框架下去，那么首先在最年轻的（新）时间框架上OnInit，然后在最老的（旧）时间框架上OnDeinit。

如果开关向上，那么反之亦然。首先在较低（较旧）的时间框架上OnDeinit，然后在较高（较新）的时间框架上OnInit。

你应该记住，缓存是从低阶时间框架到高阶时间框架的处理。

你是照实说，还是像准备新建筑时那样说？

如果是这样，那我就错了，我收回我的话。

 
Alexey Viktorov:

在这个消息中。

你是说按原样还是按准备新建的方式？

如果是这样，我就误解了，收回。

这是在构建1580中完成的。

在此之前，时间框架变化时的去初始化几乎总是更早。但只有在时间框架开关关闭的情况下，去初始化是用代码1完成的，而不是3，因为它应该是这样。

 
Slawa:

这是在构建1580中完成的

在此之前，在切换时间框架时，去初始化几乎总是提前进行。但只有在时间框架开关关闭的情况下，去初始化是用代码1完成的，而不是应该的3。


那么，如何处理Inite指标中的这些去初始化的代码，这些代码是做什么的？因为没有可能在指标中等待，所以睡眠 不起作用。
1234567891011121314...28
新评论