Init()和DeInit()执行顺序 - 页 4 1234567891011...28 新评论 Sergey Chalyshev 2017.04.10 22:33 #31 fxsaber:在Deinit中，将所有数据写入globals中。通过GlobalVariableSetOnCondition 将其中一个globals设置为信号。在Init中，如果信号灯处于 "dumped "状态，我们将通过将信号灯设置为 "read all "状态来读取和工作。如果信号灯是 "不可理解的"，那么我们就等待信号灯（通过一个循环的Sleep 或OnTimer）。如果完全没有信号，这意味着我们第一次启动并计算所有的东西，同时我们为TF的非未来变化创建一个信号。这样的实施有什么好复杂的？要用图书馆开一次药，就这样了。 如果睡眠在指标中工作，那就更容易了。睡眠在 指标上 不起作用。 fxsaber 2017.04.10 22:38 #32 Stanislav Korotky: 如果你把小人物的数量相加，他们--每个人都自己，一次又一次地--解决一个共同的问题，那么浪费的工时就会多次（在极限情况下，是无限次;-)）超过在终端本身进行任何形式的编辑所需的时间。即使有一个假想的图书馆存在，也不能保证每个人都知道它的存在并需要使用它。一般来说，不清楚为什么要制作和留下这样的 "耙子"？因此，这不是一个耙子，而是当指标的新副本不知道旧副本时的逻辑行为。这是符合逻辑的!但有一万人希望有额外的功能，以便副本确实知道！"。那么，是什么阻止了这些单位编写一次解决方案并使用它呢？为什么要假装关心别人。真正需要它的人，会先找一个解决方案。如果他们不这样做--他们会尝试写一个。一个集中的代码库正是为了这个目的。 fxsaber 2017.04.10 22:39 #33 Sergey Chalyshev: 如果睡眠在指标中工作，那就更容易了。睡眠在 指标上 不起作用。 OnTimer建议。这个问题并不是什么大问题。 Stanislav Korotky 2017.04.10 22:49 #34 fxsaber:因此，这不是一个耙子，而是当指标的新副本不知道旧副本时的逻辑行为。这是符合逻辑的!但有一万人希望有额外的功能，以便副本确实知道！"。那么，是什么阻止了这些单位编写一次解决方案并使用它呢？为什么要假装关心别人。真正需要它的人，会先找一个解决方案。如果他们不这样做--他们会尝试写一个。一个集中的kodobase正是为了这个目的。不，这不是那么简单。指标在另一个实体--图表/曲线图内，并从属于它（我知道它们之间复杂的一对多关系，但这并不改变其本质）。一个图表有自己的生命周期，其中包括某种内部的init和deinit事件，这是指标生命周期的边界。换句话说，一个指标不能超过其图表的寿命。图表的deinit必须等待所有指标的deinit或deinit的timeout。只有这样，才能启动新时间框架的图表初始化，并从中调用附加指标的初始化。顾名思义，耙子是可以被踩在脚下的东西。已经被踩在脚下了。好的软件原则上不允许有耙子。 Sergey Chalyshev 2017.04.10 22:54 #35 fxsaber:因此，这不是一个耙子，而是当指标的新副本不知道旧副本时 的逻辑行为。这是符合逻辑的!但有一万人希望有额外的功能，以便副本确实知道！"。那么，是什么阻止了这些单位编写一次解决方案并使用它呢？为什么要假装关心别人。真正需要它的人，会先找一个解决方案。如果他们不这样做--他们会尝试写一个。一个集中的kodobase正好起到了同样的作用。 当你切换时间框架并再次输入输入参数时，你怎么会不知道呢？ Andrey Dik 2017.04.11 03:39 #36 Sergey Chalyshev: 然后Deinit将完成它的工作，破坏一切。如果你做自己的自定义Init和Deinit，常规的Init和Deinit就没有意义了。我也遇到过这个问题。(我已经告诉了你一切，但我要补充一些我自己的东西。所有MT的程序的特殊性在于它们是基于事件而工作的。根据事件模型，OnInit和OnDeinit的工作相当有逻辑性，也很恰当。但是，输入变量的行为有一个奇怪的细微差别：所有的基本指标，包括内部终端指标和那些包含在标准交付中的指标--每次启动它们时，都会使用自上次启动以来被调用的相同的输入参数。它非常方便。但对于自定义指标 和所有的专家顾问和脚本（包括标准的）来说，没有这样的东西，这是一些不便之处（希望MQ：为输入变量增加与标准指标相同的行为）。关于Init和Deinit的工作，就我个人而言，在处理程序的全局变量时，我从来没有考虑过程序去初始化的原因，我总是在程序的具体想法下建立逻辑。例如，很多时候有必要在EA去初始化后保存程序的全局变量（原因可能是不同的，例如同一个断开导致OnDeinit和随后的OnInit），那么为什么要为此重新计算和创建新的指标柄等？ 这就是为什么，正如我之前和fxsaber 写的那样，如果你在某些情况下需要保存程序的全局变量--你可以在终端的全局变量中使用适当的标志来完成它。不幸的是，在MQL中不是一切都很顺利，但OnInit和Ondeinit的工作是合乎逻辑的，可以理解的，所以是浪费时间）。 Andrey Dik 2017.04.11 03:40 #37 Sergey Chalyshev: 你不知道是什么意思，当你切换时间框架时，你是否重新输入输入参数？ 我刚刚检查了一下--不，在切换TF的时候，你不必重新输入输入变量。 Nikolai Semko 2017.04.11 04:31 #38 Andrey Dik:但OnInit和Ondeinit的工作原理是合乎逻辑和可以理解的，所以没有必要大惊小怪)。 请解释一下当你切换时间框架时，指标中OnInit和OnDeinit的顺序逻辑。我将非常感激。而且我想我不是唯一的一个。 Andrey Dik 2017.04.11 04:44 #39 Nikolai Semko: 请解释一下当你切换时间框架时，指标中OnInit和OnDeinit操作的逻辑顺序。我将非常感谢你。而且我想我不是唯一的一个。斯拉瓦先生说得很清楚。一个指标的副本被创建，旧的指标在一段时间后被卸载。如果我们想保存程序的全局变量，我们应该在调用OnInit的时候就已经处理好了（客户终端的全局变量很适合这个目的）。 而指标缓冲区无论如何都会被重新计算，因为条形图（蜡烛图）已经改变，显然，这就是为什么会发生这种情况（复制会开始，而之前的指标实例会被终端完成）。如果指标开发者看到了处理图形对象的问题，那么在指标开始时，有必要将图形对象的名称与TF的名称绑定，那么指标的新副本将创建新的对象，而指标的上一个副本将清理旧的对象。完全没有问题。 关于交易、自动交易系统和交易策略测试的论坛 Init()和DeInit()执行顺序 Slawa, 2017.04.07 15:31 它打乱了什么样的逻辑？当你改变时间框架时，会创建一个新的指标副本，它对之前的副本一无所知。有一段时间（很短的时间），指标的两个副本都是平行存在的。然后卸下之前的副本。阅读文件https://www.mql5.com/ru/docs/runtime/running Nikolai Semko 2017.04.11 04:50 #40 Andrey Dik:斯拉瓦先生说得很清楚。一个指标的副本被创建，旧的指标在一段时间后被卸载。如果我们想保存程序的全局变量，我们应该在调用OnInit的时候就已经处理好了（客户终端的全局变量很适合这个目的）。 而指标缓冲区无论如何都会被重新计算，因为条形图（蜡烛图）已经改变，显然，这就是为什么会发生这种情况（复制会开始，而之前的指标实例会被终端完成）。如果指标开发者看到了处理图形对象的问题，那么在启动指标时，应该将图形对象的名称与TF的名称绑定，那么指标的新副本将创建新的对象，而指标的上一个副本将清理其数据。没有任何问题。 是的，这很清楚。我问的是执行顺序的逻辑问题。问题是，不存在这样的逻辑。有时OnDeinit先被执行（按照普通人的逻辑应该如此），而有时OnInit先被执行。我的理解是，答案在于"在一定的时间内（很短的时间），指标的两个副本都是平行存在的 " 这句话。但这并没有使问题变得更加清晰。 1234567891011...28 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
在Deinit中，将所有数据写入globals中。通过GlobalVariableSetOnCondition 将其中一个globals设置为信号。
在Init中，如果信号灯处于 "dumped "状态，我们将通过将信号灯设置为 "read all "状态来读取和工作。
如果信号灯是 "不可理解的"，那么我们就等待信号灯（通过一个循环的Sleep 或OnTimer）。
如果完全没有信号，这意味着我们第一次启动并计算所有的东西，同时我们为TF的非未来变化创建一个信号。
这样的实施有什么好复杂的？要用图书馆开一次药，就这样了。
如果睡眠在指标中工作，那就更容易了。睡眠在 指标上 不起作用。
如果你把小人物的数量相加，他们--每个人都自己，一次又一次地--解决一个共同的问题，那么浪费的工时就会多次（在极限情况下，是无限次;-)）超过在终端本身进行任何形式的编辑所需的时间。即使有一个假想的图书馆存在，也不能保证每个人都知道它的存在并需要使用它。一般来说，不清楚为什么要制作和留下这样的 "耙子"？
因此，这不是一个耙子，而是当指标的新副本不知道旧副本时的逻辑行为。这是符合逻辑的!
但有一万人希望有额外的功能，以便副本确实知道！"。那么，是什么阻止了这些单位编写一次解决方案并使用它呢？
为什么要假装关心别人。真正需要它的人，会先找一个解决方案。如果他们不这样做--他们会尝试写一个。一个集中的代码库正是为了这个目的。
如果睡眠在指标中工作，那就更容易了。睡眠在 指标上 不起作用。
因此，这不是一个耙子，而是当指标的新副本不知道旧副本时的逻辑行为。这是符合逻辑的!
但有一万人希望有额外的功能，以便副本确实知道！"。那么，是什么阻止了这些单位编写一次解决方案并使用它呢？
为什么要假装关心别人。真正需要它的人，会先找一个解决方案。如果他们不这样做--他们会尝试写一个。一个集中的kodobase正是为了这个目的。
不，这不是那么简单。指标在另一个实体--图表/曲线图内，并从属于它（我知道它们之间复杂的一对多关系，但这并不改变其本质）。一个图表有自己的生命周期，其中包括某种内部的init和deinit事件，这是指标生命周期的边界。换句话说，一个指标不能超过其图表的寿命。图表的deinit必须等待所有指标的deinit或deinit的timeout。只有这样，才能启动新时间框架的图表初始化，并从中调用附加指标的初始化。
顾名思义，耙子是可以被踩在脚下的东西。已经被踩在脚下了。好的软件原则上不允许有耙子。
因此，这不是一个耙子，而是当指标的新副本不知道旧副本时 的逻辑行为。这是符合逻辑的!
但有一万人希望有额外的功能，以便副本确实知道！"。那么，是什么阻止了这些单位编写一次解决方案并使用它呢？
为什么要假装关心别人。真正需要它的人，会先找一个解决方案。如果他们不这样做--他们会尝试写一个。一个集中的kodobase正好起到了同样的作用。
当你切换时间框架并再次输入输入参数时，你怎么会不知道呢？
然后Deinit将完成它的工作，破坏一切。如果你做自己的自定义Init和Deinit，常规的Init和Deinit就没有意义了。
我也遇到过这个问题。(
我已经告诉了你一切，但我要补充一些我自己的东西。
所有MT的程序的特殊性在于它们是基于事件而工作的。根据事件模型，OnInit和OnDeinit的工作相当有逻辑性，也很恰当。
但是，输入变量的行为有一个奇怪的细微差别：所有的基本指标，包括内部终端指标和那些包含在标准交付中的指标--每次启动它们时，都会使用自上次启动以来被调用的相同的输入参数。它非常方便。但对于自定义指标 和所有的专家顾问和脚本（包括标准的）来说，没有这样的东西，这是一些不便之处（希望MQ：为输入变量增加与标准指标相同的行为）。
关于Init和Deinit的工作，就我个人而言，在处理程序的全局变量时，我从来没有考虑过程序去初始化的原因，我总是在程序的具体想法下建立逻辑。例如，很多时候有必要在EA去初始化后保存程序的全局变量（原因可能是不同的，例如同一个断开导致OnDeinit和随后的OnInit），那么为什么要为此重新计算和创建新的指标柄等？
这就是为什么，正如我之前和fxsaber 写的那样，如果你在某些情况下需要保存程序的全局变量--你可以在终端的全局变量中使用适当的标志来完成它。
不幸的是，在MQL中不是一切都很顺利，但OnInit和Ondeinit的工作是合乎逻辑的，可以理解的，所以是浪费时间）。
你不知道是什么意思，当你切换时间框架时，你是否重新输入输入参数？
但OnInit和Ondeinit的工作原理是合乎逻辑和可以理解的，所以没有必要大惊小怪)。
请解释一下当你切换时间框架时，指标中OnInit和OnDeinit的顺序逻辑。我将非常感激。而且我想我不是唯一的一个。
请解释一下当你切换时间框架时，指标中OnInit和OnDeinit操作的逻辑顺序。我将非常感谢你。而且我想我不是唯一的一个。
斯拉瓦先生说得很清楚。
一个指标的副本被创建，旧的指标在一段时间后被卸载。
如果我们想保存程序的全局变量，我们应该在调用OnInit的时候就已经处理好了（客户终端的全局变量很适合这个目的）。
而指标缓冲区无论如何都会被重新计算，因为条形图（蜡烛图）已经改变，显然，这就是为什么会发生这种情况（复制会开始，而之前的指标实例会被终端完成）。
如果指标开发者看到了处理图形对象的问题，那么在指标开始时，有必要将图形对象的名称与TF的名称绑定，那么指标的新副本将创建新的对象，而指标的上一个副本将清理旧的对象。
完全没有问题。
关于交易、自动交易系统和交易策略测试的论坛
Init()和DeInit()执行顺序
Slawa, 2017.04.07 15:31
它打乱了什么样的逻辑？
当你改变时间框架时，会创建一个新的指标副本，它对之前的副本一无所知。有一段时间（很短的时间），指标的两个副本都是平行存在的。然后卸下之前的副本。
阅读文件https://www.mql5.com/ru/docs/runtime/running
斯拉瓦先生说得很清楚。
一个指标的副本被创建，旧的指标在一段时间后被卸载。
如果我们想保存程序的全局变量，我们应该在调用OnInit的时候就已经处理好了（客户终端的全局变量很适合这个目的）。
而指标缓冲区无论如何都会被重新计算，因为条形图（蜡烛图）已经改变，显然，这就是为什么会发生这种情况（复制会开始，而之前的指标实例会被终端完成）。
如果指标开发者看到了处理图形对象的问题，那么在启动指标时，应该将图形对象的名称与TF的名称绑定，那么指标的新副本将创建新的对象，而指标的上一个副本将清理其数据。
没有任何问题。
是的，这很清楚。我问的是执行顺序的逻辑问题。问题是，不存在这样的逻辑。有时OnDeinit先被执行（按照普通人的逻辑应该如此），而有时OnInit先被执行。
我的理解是，答案在于"在一定的时间内（很短的时间），指标的两个副本都是平行存在的 " 这句话。但这并没有使问题变得更加清晰。