贸易交易时
我对开发者的回答很感兴趣--为什么OnTradeTransaction 事件不能保证？
开发商可能已经厌倦了回答。我将努力为他们解答。根据定义，OnTradeTransaction 不能被保证，因为它是一个事件。即使事件被保证发送，也不能保证被接受。想象一下，当一个事件发生时，用户终端关闭或与互联网的连接中断，这个事件无法被处理。概率很低，但并非不可能。
与其分析事件，不如分析交易环境的状态，只有当交易环境发生变化时，才做出必要的决定。OnTransaction只能在非常有限的情况下使用，通常不使用它更好。看看MetaTrader 4，它没有OnTransaction，没有它也能管理得很好。
开发商可能已经厌倦了回答。我将努力为他们解答。根据定义，OnTradeTransaction不能被保证，因为它是一个事件。即使事件被保证发送，也不能保证被接受。想象一下，当一个事件发生时，用户终端关闭或与互联网的连接中断，这个事件无法被处理。概率很低，但并非不可能。
与其分析事件，不如分析贸易环境，只有当贸易环境发生变化时，才做出必要的决定。OnTransaction只能在非常有限的情况下使用，通常不使用它更好。看看MetaTrader 4，它没有OnTransaction，没有它大家都做得很好。
与mt5不同，在mt4中管理头寸要容易得多，因为没有净额结算，所以OnTransaction在那里是好是坏。
也就是说，该事件不被保证只是因为技术原因？如果一切正常，那么终端应该100%保证这个事件？
在MT4中，由于没有净额结算，管理头寸要比MT5容易得多。 这就是为什么在MetaTrader中OnTransaction是热的或冷的。
因此，该事件不能保证只是因为技术原因？如果一切正常，那么终端应该100%保证这个事件？
净额结算对OnTradeTransaction 的需求没有影响。
第二个问题只能由开发者自己来回答。我所注意到的是，OnTradeTransaction是非常稳定的。没有发现事件接收损失。
净额结算对OnTradeTransaction的需求没有影响。
净额结算会影响头寸核算，也是这么简单的问题出现这么多问题的原因，而头寸核算也需要OnTradeTransaction。
在MT4中，由于没有净额结算，一般来说，管理头寸要比MT5容易得多，所以OnTransaction在那里不冷不热。
因此，该事件不能保证只是因为技术原因？如果一切正常，那么终端应该100%保证这个事件？
开发人员选择优先的产品属性。 MT4的优先属性是易于使用MQL4。
对于MT5，明显的第一级优先事项是速度（和灵活性）。不可能最大限度地获得一个产品的所有功能。这与理论相矛盾。
最快的产品将不可避免地需要客户的程序员付出更多（知识、经验和努力）。
这些技术问题是什么鬼。让我们冷静地想一想。
假设你正在开发一个MT5，你有一个任务：为交易行为编写一个HFT块。
一方面，交易记录从服务器排队，另一方面，这些记录必须传递给XXX-专家。
在XXX专家中，在OnTradeTransaction() 处理程序中，用户可以有任何 "色情"!
绝对不清楚这一功能将执行多长时间。
该队列可能包含数百条来自服务器但尚未转移到XXX-expert的记录。
在这种情况下，你能保证什么？数据的速度或完整性？
而且，为一个本质上只对HFT有贡献的功能 "储存 "深度过时的信息是否有任何意义？
伙计们!
我读到这里，不禁感叹...
OnTradeTransaction让你无需在任何地方 "挖掘 "就能获得最新的信息。
在订单和交易上!
你只是不知道如何使用这个功能。
你也不知道怎么做。你已经写了几十页关于OnTradeTransaction的主题，但你没有搞清楚一件事：OnTradeTransaction是一个服务功能，旨在解决狭窄的特定任务，你不能像你那样在交易中使用它。然后聪明的人读了你的文章，创造了类似的主题："为什么OnTradeTransaction没有保证？" - 因为专家顾问不应该像你那样通过OnTradeTransaction创造其交易环境，而只依靠系统中的内容，特别是订单 和交易历史。
一方面，是的。另一方面：如果请求已经被发送到服务器，但操作还没有被执行，怎么办？如果我们只有一个订单和头寸的清单（以及账户历史），我们怎么能知道我们处于什么状态？
在MT4中没有这样的问题，因为那里的所有交易操作都是同步的。但结果是我们得到了更慢的性能。
一方面，是的。另一方面：如果请求已经被发送到服务器，但操作还没有被执行，怎么办？如果我们只有一个订单和头寸的清单（以及账户历史），我们怎么能知道我们处于什么状态？
在MT4中没有这样的问题，因为那里所有的交易操作都是同步的。但结果是，我们得到了更慢的性能。
如果发送订单和下一个入市信号之间的时间超过了订单执行 的时间，我们将不需要做任何事情。逻辑很简单：我们发送一个异步订单，离开线程并忘记它。我们等待下一个时刻来检查信号。如果在那一刻，交易环境没有改变--专家顾问会寻找再次入市的信号，并重复入市的命令。相反，如果一切顺利，订单被执行，专家顾问在分析环境后会意识到它有一个仓位，不会再开新仓。即，在这种方法中，专家顾问的条件被保证与市场环境一致。
在高频交易中，情况更为复杂，新的信号可能在与执行订单相当的时间（6-100毫秒）后出现。在这种情况下，你不能不锁定。专家顾问应该记住最后一次发送订单的时间。如果在OnTransaction中发生错误，锁定会被重置，专家顾问可以再次执行交易。
应该指出的是，许多人喜欢祈祷的OnTradeTransacton在HFT没有帮助。一个新的进入信号可以比OnTradeTransaction中关于成功执行交易的响应更快地到达。无论你是否使用OnTradeTransacton，封锁是必要的。
你可能会问，我们如何才能控制OnTradeTransaction中产生的错误？你可以用一个反问来回答： 当错误发生时，你将如何即时改变专家顾问的交易逻辑？- 你不能。如果你在之前没有做适当的检查（钱的存在、数量等），就会出现错误。但是一旦发生，你将无法纠正它。因此，在OnTradeTransaction中，你能做的最好的事情是将这个错误打印到日志中（以便以后纠正专家顾问的逻辑），并删除锁，如果它被使用。为此，除此之外，必须使用OnTradeTransaction。
现在米卡拉斯的各种信徒会跑进来，开始向我扔西红柿--让他们来吧。但我一直重复，只有基于终端的交易环境，才能组织起可靠的交易逻辑。其他任何东西都不起作用。
我对开发者的回答很感兴趣--为什么OnTradeTransaction 事件不能保证？
OnTradeTransaction是服务器对OrderSendAsinc请求的响应结果。
OrderSendAsinc函数本身是异步的，这甚至在它的名字中都有说明。这意味着该函数向服务器发起请求，并向程序返回关于发送结果的响应（无论请求是否成功发送）。
这是根据公鸡打鸣，天不会亮的原则。这就是为什么服务器在OnTradeTransaction 中的回复不被保证。你永远不知道那里可能发生什么。
有两个类似的函数OrderSend和OrderSendAsinc。
第一个是同步的，默默地等待服务器的回复，无论需要多长时间（它返回服务器处理请求的结果）。
第二种是异步的，它不等待服务器的响应，而是立即返回操作的结果（但返回请求是否成功发送到服务器的结果）。
当需要快速做出决定时，就需要OrderSendAsinc。测试表明，OrderSendAsinc可以处理每秒钟发送数百个请求（但这个速度是由于它没有等待服务器的响应）。
确切地说，对于收到 "延迟 "的回复，终端产生OnTradeTransaction事件（延迟是有条件的，因为程序继续接收回复，事实上，滞后是以秒或毫秒计算的）。
与OrderSend不同的是，OnTradeTransaction可以为一个订单多次生成，通知终端新收到的关于服务器如何处理该请求的信息。这意味着我们可以在OnTradeTransaction中看到订单处理的阶段。
被服务器接受的订单 OnTradeTransaction
该订单已被置于OnTradeTransaction队列中。
订购...贸易交易时
订购...OnTradeTransaction等。
除了订单上的第一个事件外，所有的事件都有票据签名，以确定OnTradeTransaction事件的响应是由哪个订单接收的。
第一个事件是由票据和request_id签署的。用户在提交订单后立即从OrderSendAsinc函数中获得 request_id。因此，一个具体的OrderSendAsinc迭代与OnTradeTransaction中获得的结果相关联。
