Предпосылки очень просты -- таймер обычно используется для синхронизации (ждем расчета данных) или обсервинга (зацикленный таймером эксперт, имхо, будет гораздо более адекватным).
У вас в mql4 стоит проскальзывание 50, а в mql5 10. Попробуйте поставить одинаковое проскальзывание возможно ситуация выровняется тк много приказов с таким слипажем может просто попадать на реквот.
摘自《手册》。
Все возникающие события клиентский терминал складывает в общую очередь.
...事件队列的大小是有限的。
那么，到底有没有人要帮我呢？在第25页，两位议员...
被骂了--被骂了。现在帮助我理解。你指责我没有给你足够的数据来分析问题。我不需要任何更多。你可以检查任何你想要的东西。
我想每个人都在测试我的机器人......。我等着。可能需要花钱雇一个程序员来帮助找到一个错误。
顺便说一下，还有人记得这个主题叫什么吗....？
摘自《手册》。
有一些关于事件队列的讨论，但我找不到确切的尺寸。事件队列有多深？64?256？ ...事件？
我还想问一下，如果事件队列开始积累和窒息，会发生什么？新的事件会被忽略吗，还是已经在队列中的事件会被重置？当然，这将在何时发生（在队列中的哪个事件）？
已回答
https://www.mql5.com/ru/forum/1621/43941#comment_43941
已回答
https://www.mql5.com/ru/forum/1621/43941#comment_43941
我认为仍然需要澄清，有一个答案，但它是模糊的，我的问题甚至没有得到暗示。
既没有确切说明队列的长度，也没有说明哪些事件将被跳过（你说的 "部分事件将被跳过 "是什么意思？"什么部分？"，新事件还是已经在队列中的事件？"逻辑在这里无能为力，因为新事件可能比队列中的事件更重要，或者相反。
所以最好能澄清这一点。
那么，到底有没有人要帮我呢？在第25页，两位议员...
骂人就是骂人。现在帮助我理解。你指责我没有给你足够的数据来分析问题。我不需要任何更多。你可以检查任何你想要的东西。
我想每个人都在测试我的机器人......。我等着。可能需要花钱雇一个程序员来帮助找到一个错误。
顺便说一下，还有人记得这个主题叫什么吗....？
你在mql4中的滑动量为50，在mql5中为10。试着设置相同的滑点，也许情况会持平，因为许多有这样滑点的订单可能只是进入重新报价。
更好的是，在这两种变体中，将滑移量设置为价差大小。
我将重复这个问题。
我如何正确地删除所有带有某种魔力的订单？
...我需要从上到下浏览订单列表，例如像这样。
我试着按你说的做了，但问题仍然存在--先是删除了待定订单，然后又发出另一个请求来删除同一订单。下面是一个日志行的例子。
2011.05.12 16:42:57 Traes '726238' : 取消订单 #4388299 买入止损 0.02 EURUSD at 1.41700 完成- 订单成功删除
2011.05.12 16:42:57 交易 '726238' : 取消订单 #4388299 买入止损 0.02 EURUSD at 1.41700- 另一个请求正在发送中
2011.05.12 16:42:58 交易 '726238' : 取消订单#4388299买入0.00 at 0.00000失败 [无效请求]- 它是买入的，因为某些原因。
这种情况不是每次都发生，但有时会发生，而且不影响专家顾问的操作。我只是想让一切都变得正确，不要用空的请求来加载贸易服务器，并了解这个问题。
感谢你们的答复和你们愿意提供的帮助。
-----------------
我将尝试提出我的意见。删除具有某个神奇数字的订单或任何其他订单都不会改变，纵向或横向滚动浏览订单也是如此。你可以记住一个订单，然后通过票据删除它，错误偶尔会弹出来。
正如我所想象的那样，服务器确实已经删除了该订单，日志中的信息和服务器的retcode响应都证明了这一点。但终端还不知道，也就是说，这个订单对它来说仍然有效（或者它知道，但它给EA的信息是过时的，尽管那时它就没有通过检查），在下一次打勾时，它又发出了删除请求，并从服务器上得到一个错误。
事实上，服务器把买入止损单变成了简单的买入单，这似乎是服务器的一个错误：在请求错误的情况下，它没有区分这些订单。这是开发人员需要记住的事情。
我们如何才能避免重复请求？我认为只有两种方法。
1.删除成功后，分析最后的历史，等待被删除的订单出现在其中，然后继续。
2.简单地引入一个延迟，比如两秒，在删除完成后。一秒钟可能是不够的。
我还想补充一点，这种情况不仅发生在挂单上，也发生在市价订单上，以及仓位改变时。这种情况很少发生，可能只有在模拟账户上长期交易时才会注意到，但在测试器中，当然不会显示出来。另外，在改变头寸后，改变前的保证金水平会发生逆转，可能还有其他账户参数，我没有检查。
У вас в mql4 стоит проскальзывание 50, а в mql5 10. Попробуйте поставить одинаковое проскальзывание возможно ситуация выровняется тк много приказов с таким слипажем может просто попадать на реквот.
而更好的是，在这两个变体中，将滑点设置为点差的大小。
我会试试的，但情况不太可能有明显的改善。
我在编程方面有问题还是一切正常？
我认为仍然需要澄清，有一个答案，但它是模糊的，我的问题甚至没有得到暗示。
既没有确切说明队列的长度，也没有说明哪些事件会被跳过（你说的 "部分事件会被跳过 "是什么意思？"什么部分？"，新事件还是已经在队列中的事件？"逻辑在这里是无能为力的，因为也许新事件可能比队列中的事件更重要，也许反过来也一样。
所以最好能澄清这一点。
1)"公共队列中的堆栈"--文档中的错误。实际上有很多排队的人。目前，每个mql5程序 和每个图表都有自己的队列。队列的大小不同，一般来说都不小，对于一个正确编写的程序来说，队列的溢出是不太可能的。我们不会记录每个队列的确切大小，它们的数量，或任何其他内部实现的详细描述。原因很明显--内部实施可以改变。
2) 任何新的事件，如果在这个特定的队列中没有足够的空间，将被跳过。
让我提醒你，在mql5程序的传入事件队列中，一个新的tick和图表变化的事件只能存在于一个实例中。可以启用/禁用图表上图形对象的创建和删除事件的生成。
你能告诉我底部的那些绿条是什么意思吗？在MT4中，它们指的是手数，在手数变化时被抽出。但它在这里有什么用呢？还是我的手数变化？似乎我没有改变它。