对MT5的祝愿 - 页 50

[Andrey Khatimlianskii]

Yedelkin:

好吧，因为手册上说"NewTick 事件产生于 当EA连接到图表的符号上收到一个新的tick时。"，收到新的ticks的事实应该引起NewTick 事件的产生。

根据问题判断，你认为当OnTick()被禁用时，不会产生NewTick 事件？但我在参考手册中没有找到这样的信息。

这就是我的看法--如果没有处理程序，事件就不会被排队。这是符合逻辑的，我不认为在帮助中写这个问题有什么意义。

专家顾问产生了大量的事件（交易事件，来自图表等），没有必要全部处理。

如果所有的事件（包括未处理的事件）都被排队，一些EA将无法工作--他们的事件无法进入队列（例如，当每天只在定时器上工作一次）。

[[删除]]

komposter:

我是这样看的--如果没有处理程序，事件将不会被排队。这是符合逻辑的，我不认为在帮助中写这个问题有什么意义。

专家顾问产生了大量的事件（交易事件、图表事件等），没有必要全部处理它们。

如果所有的事件（包括未处理的事件）都放在同一个队列中，一些Expert Advisors将无法工作--他们的事件无法进入队列（例如，当每天只有计时器工作一次时）。

在我看来，这两类事件（NewTick和Timer）必须与其他事件分开处理。

最有可能的是，我们还应该把交易事件（Trade）和处理市场深度的事件（BookEvent）分开。

[Yedelkin]

利扎尔，有意思。

我对测试器操作的结论是错误的。显然，我把演示日志误认为是测试员的日志。的设计

void OnChartEvent(const int id,           
                const long& lparam,   
                const double& dparam, 
                const string& sparam  
                )
  {
   if(id==CHARTEVENT_CUSTOM) TesterWithdrawal(1);
  }

对我来说还不适用。这表明来自其他符号上的指标的用户事件CHARTEVENT_CUSTOM 没有被接收或没有被处理。

[Yedelkin]

komposter:

我相信是这样的--如果没有处理程序，事件就不会被排队。

如果这个版本得到确认就好了。但对于测试人员来说，无论如何都会产生蜱虫。即使是在绝对没有必要的时候。

komposter:

这是符合逻辑的，我不认为有任何理由在帮助中写到这一点。

也许这是符合逻辑的，但并不适合所有人。开发人员多次斥责用户想太多。因此，在我的结论中，我试图只以目前可获得的信息为基础。目前，如前所述，手册上说" 当收到符号的新刻度线时，就会产生NewTick 事件，该符号与专家顾问所在的图表相连"。我没有找到任何例外条款，所以我得出的结论是，收到新刻度的事实必须导致NewTick 事件的产生。

komposter:

专家顾问产生了大量的事件（交易事件，来自图表等），没有必要全部处理。

为了确保NewTick 事件不被处理，我建议做一个开关函数。专家顾问将能够自己决定是否需要由终端生成NewTick 事件。 我的专家顾问应该只与 "外来 "信号一起工作，但它仍然需要连接到一些图表。而事实证明，例如，在测试/优化过程中，一定数量的时间花在为专家顾问所连接的符号生成ticks 上，而专家顾问根本不需要这些ticks（和NewTick 事件）。

[Andrey Khatimlianskii]

Yedelkin:

但是对于测试人员来说，无论如何都会产生蜱虫。即使他们完全没有必要。

这是什么意思呢？它将检查在什么价格下触发的订单（挂单、SL和TP）？

在测试器中，我们需要所有符号的刻度，专家顾问在这些符号上交易。当然，仪器的数量越多，建模的质量越高，操作就越慢。

耶德尔金。

目前，如上所述，手册上说" 当专家顾问所连接的图表上出现新的刻度线时，就会产生NewTick 事件"。 我没有发现这一规则的任何例外条款，因此我得出结论，新刻度线的到来应该产生NewTick 事件。

是的，但按照这个逻辑，所有其他事件都应该以同样的方式排队。那就太过分了。

[Yedelkin]

komposter:

怎么说呢？它将在什么价格检查订单的触发（挂单、SL和TP）？

好吧，我再重复一遍：该EA根本就没有与之相连的符号工作。而且它不需要跟踪这个符号的SL和TP。也就是说，EA不需要这个符号的ticks。EA只有在必要时才附在符号上，因为它至少需要附在某个地方才能被触发。

康帕斯。

是的，但按照这个逻辑，所有其他事件必须以完全相同的方式排队。这将是太多了。

遵循这一逻辑，所有生成蜱虫和/或排队事件的规则的例外情况都应在参考书中列出。到目前为止，我只发现了一个例外，--对于这样一种情况：（1）有一个函数OnTick()，（2）这个函数处理前一个事件NewTick。这种例外并不适合我的情况。

[[删除]]

Yedelkin:

遵循这一逻辑，所有生成蜱虫和/或排队事件的规则的例外情况都应在手册中列出。到目前为止，我只发现了一个例外--对于以下情况：（1）有一个函数OnTick()，（2）这个函数处理前一个NewTick 事件。这个例外不适合我的情况。

合乎逻辑的是，如果OnTick()不存在，就没有对这个图表的ticks进行处理（通过这个图表的符号）。

事件是否被排队，在什么队列中是另一个问题。最主要的是，图表（上面的专家顾问）并没有对ticks进行处理!

如果我们考虑到EA处理来自其他图表的ticks，我们将需要考虑处理EXTERNAL ticks。

因此，在我看来，在我的专家顾问中应该创建自己的ticks处理，在其中作为输入参数传递：符号、时间、价格（自定义事件理论上可以做到这一切）。

我认为需要详细研究和优化的是定制事件potk的工作。

[Yedelkin]

Interesting:

如果考虑到EA处理来自其他图表的ticks，那么有必要对外部ticks进行处理。

因此，在我看来，在Expert Advisor中应该创建自己的ticks处理，在其中作为输入参数传递：符号、时间、价格（自定义事件理论上可以做到这一切）。

在我看来，只需对自定义事件potk的工作进行详细的研究和优化。

你是对的，这正是我的方法，只处理外部蜱虫。这里还没有问题。

有趣的 是:

合乎逻辑的是，如果OnTick()不存在，就不会对这个图表的ticks（根据这个图表的符号）进行处理。

事件是否被排队，在什么队列中是另一个问题。最主要的是，图表（上面的专家顾问）并没有对ticks进行处理!

因此，我一直致力于确保 在我的情况下，一般队列不会被 "内部 "抽签的事件堵塞。当然，我可能是错的，但 "禁用 "应该比 "确保及时生成刻度线、适当的事件队列、与服务器同步等 "容易得多......让大多数人的 "默认 "保持目前的状态，对于像我这样的极端人士，增加一个禁用/切换功能。如果可能有任何副作用，请在手册中注明注意事项。

[[删除]]

Yedelkin:

没错，这正是我的方法--完全通过处理外部蜱虫。这里还没有问题。

这就是我所固定的，以确保 在我的情况下，一般的队列不会被 "内部 "蜱虫的事件所堵塞。当然，我可能是错的，但 "禁用 "应该比 "确保及时生成刻度线、适当的事件队列、与服务器同步等 "容易得多......让大多数人的 "默认 "保持目前的状态，但对于像我这样的极端人士，增加一个禁用/切换功能。如果可能有任何副作用，请在手册中注明注意事项。

至于更容易，这是一个有争议的问题，而你提出的变体也同样有争议（在我看来）。

关于ticks和所有事件的整个问题是，如果Expert Advisor中没有处理程序，事件会发生什么。

我在这方面的第二个问题是--所有事件都在同一个队列中处理，还是某些事件（OnTimer、OnTick和OnTrade）有自己的队列？

[Yedelkin]

Interesting:

更容易是值得商榷的，而你提出的方案也同样值得商榷（在我看来）。

我同意；你很难判断你不知道的事情。只剩下表达愿望了 :)关于我的版本的实际意义，我可以说，这里的主要内容是 "我不需要抽搐！"的想法；如何实现它将取决于开发人员。

有趣的 是。

关于ticks和所有事件的整个问题是，如果Expert Advisor中没有处理程序，事件会发生什么。

完全正确。对我来说只有一个解决办法--切断两端（引入开关功能），而且保证不会再有问题了:)但我们也应该记住那些浪费时间创造（产生）原则上不必要的标记的测试人员。只是因为测试者被迫依附于其中一个角色。

有趣的 是。

我在这方面的第二个问题是--所有事件都在一个队列中处理，还是对某些事件（OnTimer、OnTick和OnTrade）有单独的队列？

那么，手册中明确指出，"所有发生的事件 "都被放入一个共同的 队列中，并按照收到的顺序一个接一个 地处理。唯一的例外是为NewTick指定的。你以某种方式证明了OnTimer事件并不总是被处理，但它也可能因为普通队列溢出而被删除。我根本没有看到任何关于每个事件单独排队的说法。