В языке MQL5 предусмотрена обработка некоторых предопределенных событий. Функции для обработки этих событий должны быть определены в программе MQL5: имя функции, тип возвращаемого значения, состав параметров (если они есть) и их типы должны строго соответствовать описанию функции-обработчика события. Именно по типу возвращаемого значения и по...
在电脑前，没有做任何计算。没有给CPU加载任何东西。
19毫秒，执行SymbolInfoTick的时间为48毫秒。有几十个案例的持续时间是数百微秒。但我没有引用它们。
显然，为了重现它，我们需要运行战斗顾问24小时，然后只能观察。在我看来，要搞清楚是什么原因导致了这种滞后，是不现实的。
有时，计算机可能正在泵送更新或做一些服务任务。另外，电源电压的变化也会影响它。这样你就可以得到可编程的网卡，在那里所有的机器人逻辑都是硬接线:)但即使在那里也会因为量子场的波动而出现延迟。
开发商已经尽了最大努力。而没有这一点，该分支提供了代码，显示了蜱虫是如何滞后于市场观察的，反之亦然。蜱虫的到达顺序是如何被打破的，可能还有其他的东西。总而言之，讨厌的有效代码被张贴出来，以重现其他情况。
SymbolInfoTick发送从经纪人的服务器上收到的数据。服务器发送的东西就是你得到的东西。
SymbolInfoTick()是 在阻塞模式还是在非阻塞模式下执行的？
例如，它在while循环的主体中，没有连接或市场因周末而关闭，
，那么它将通过停止循环而被阻止，还是将被异步执行？
市场观察如何滞后于市场观察，反之亦然。
也就是说，SymbolInfoTick 捕捉到一个新的tick，我们通过轮询Market Watch得到不同的Ask和Bid（不需要等待Market Watch变化事件）？这在一年多以前是不可能做到的。SymbolInfoTick和CopyTick和vintage总是导致同一个tick。如果你通过不同的OnXXX函数获得刻度，当然，你会通过一个函数得到一些东西，而通过另一个函数得到一些东西......。
也就是说，SymbolInfoTick捕捉到一个新的tick，我们通过轮询杯子得到一个不同的Ask和Bid（不需要等待杯子变化事件）？
在这里。
在这里。
我以为你在测试OnBookEvent和OnTick，而不是MarketBookGet和SymbolInfoTick。如果你用这个方案进行测试，你就会有一切匹配。
p.s 阅读你下面的帖子。你也明白。你为什么需要OnBookEvent和OnTick？在我的例子中，Sleep(1)需要1-2毫秒，用SymbloInfoTick请求和勾选需要不到MICRO秒。如果不出现滴答声，处理器在99.9%的时间里已经在休息了。使用OnBookEvent和OnTick 的好处是什么？
我以为你在测试OnBookEvent和OnTick，而不是MarketBookGet和SymbolInfoTick。如果你按照这个方案进行测试，你就会有一切匹配。
p.s 阅读你下面的帖子。你也明白。为什么你需要OnBookEvent和OnTick？在我的例子中，Sleep(1)需要1-2毫秒，用SymbloInfoTick请求和勾选需要不到MICRO秒。如果不出现滴答声，处理器在99.9%的时间里已经在休息了。使用OnBookEvent和OnTick 的好处是什么？
没有一丝一毫的外交手段，你是在胡说八道。Sleep(1)是十分之一的毫秒。我只看到一个理论化的说法。
OnTick的用户希望看到一个新的蜱虫，而不是一段时间前到达终端的那个。你可以在源代码中把SymbolInfoTick 紧接着MarketBookGet。
开发商已经完全承认他们的沉默存在两个问题。
没有一丝一毫的外交手段，你是在胡说八道。Sleep(1)是十几毫秒。我只看到一个理论化的说法。
用户希望在OnTick中看到一个新的tick，而不是一段时间前到达终端的tick。你可以在源代码中把SymbolInfoTick紧接着MarketBookGet。
开发商通过沉默，完全承认了两个问题。
并非总是如此，也并非每十分之一毫秒都是如此。用一个简单的脚本进行了检查
以下是我的日志
OnTick用户总是看到最新鲜的蜱虫。
OnBookEvent的用户总是看到最新鲜的蜱虫。
但如果你想比较用OnTick接收的ticks和用OnBookEvent接收的ticks，你会很失望，因为这些事件 是按顺序处理的，而不是并行处理的。这就是用户pivomoe试图告诉你的事情
并非总是如此，也并非处处都是十分之一毫秒的时间。用一个简单的脚本进行了检查
这是我的日志。
这是我的日志。
结果。
OnTick用户总是看到最新鲜的蜱虫。
OnBookEvent的用户总是看到最新鲜的蜱虫。
在一台不繁忙的机器上，在一个单一的图表上运行EA 的结果。
标识相同的刻度，这些刻度在不同的On-functions中由相应的方法接收。如果在六个图表而不是一个图表上运行，滞后时间可达几十毫秒。
但如果你想比较在OnTick中收到的ticks和在OnBookEvent中收到的ticks，那么你会感到失望，因为这些事件 是按顺序处理 的，而不是平行处理的。用户pivomoe试图告诉你什么
如果一个几乎为空的OnBookEvent/OnTick比相应的几乎为空的OnTick/OnBookEvent晚20毫秒被触发，这样可以吗？
ZS 当你关注这个话题的时候，这里还有一个复制代码。在市场观察中，蜱虫的出现时间比之前的市场观察时间要早。
如果一个几乎为空的OnBookEvent/OnTick比相应的几乎为空的OnTick/OnBookEvent晚20毫秒被触发，这样可以吗？
EA队列是一个可锁定的资源。当一个事件被写入队列时，专家顾问会等待（除非专家顾问目前正在处理一个事件）。
专家顾问的事件来自相应图表的事件队列，而该队列又来自相应符号的处理周期。而这种循环处理不仅将事件分配到自己的图表中，而且还做了很多其他事情。
我已经告诉你，Windows不是一个实时操作系统。