structMqlTradeResult
{
//Очень важная информация
uint retcode; // Код результата операции//Важная информация (важна при успешном запросе)
ulong deal; // Тикет сделки, если она совершенаulong order; // Тикет ордера, если он выставлен//Малосущественная информация (важна при успешном запросе, а также в случае реквоты)double volume; // Объем сделки, подтверждённый брокеромdouble price; // Цена в сделке, подтверждённая брокером
//Малосущественная информация (важна при реквоте)double bid; // Текущая рыночная цена предложения (цены реквота)double ask; // Текущая рыночная цена спроса (цены реквота)//Не существенная информацияstring comment; // Комментарий брокера к операции (по умолчанию заполняется расшифровкой)
};
好吧，你懂的。我一丝不苟地告诉你，你可以检查：OrderSend()函数 返回一个布尔值。在这种情况下，如果请求被成功检查，订单票就被写入MqlResult结构的变量中。我称其为 "返单功能"，为自己。以下是来源的链接："当使用OrderSend()函数发送购买请求时，如果请求被成功检查，你可以立即找出所创建订单的票据。
如果你要在版主的倡议下偏离主题，你有一个类似的答案：没有也永远不会有MQL5教程，所以不清楚，你在看什么教程。 ......也许，我们可以讨论一下讨论的实质，或者什么都不讨论？:)
谢谢你对 "禁令 "的答复，我明白了。
对从服务器接收响应时将会发生什么不太正确的理解。
OrderSend()确实返回了一个布尔值，但这不是最重要的--主要的是结构，在收到服务器的响应时要填入。
是的，我们确实把票据写进了结构（不仅是订单，还有交易），但它比结构中的其他信息更重要吗？
让我们来分析一下这个反应的结构。在我看来，情况大约是这样的
PS
一个结构的正确名称是MqlTradeResult而不是MqlResult （尽管在我看来这并不重要）。
如果请求是正确的并被执行，那么成交量和价格 是重要的，因为服务器 "有权 "减少交易的数据参数，它可能需要专家顾问对服务器的行动做出反应。
不幸的是，我还是不明白。
由于某种原因，你需要在返回结构中有一个 "时间 "字段。按照出现的顺序使用时间。这足以控制一个小历史。
该结构应该被称为MqlTradeResult ，而不是MqlResult（尽管在我看来这并不重要）。
对你收到服务器的响应时发生的事情的理解不完全正确。
OrderSend()确实返回一个布尔值，但这并不是最重要的。 主要的是通过接收服务器的响应来填写的结构。
是的，的确，一张票被写入结构中（不仅是订单，还有交易），但它比结构中的其他信息更重要吗？
"当使用OrderSend()函数发送购买请求时，我们可以立即知道请求被成功检查时创建的订单的票据。但与此同时，订单本身可能还没有出现在客户终端，试图用OrderSelect函数来选择它将失败。从第二句话可以看出，即使知道它的票据，也不一定能用订单属性（订单时间）来工作。因此，"按照出现的顺序使用时间 "并不是一个理想的解决方案。此外，该订单可能根本 "打不开"。我的方法将解决控制一个小历史的问题，而不管订单在进入历史之前发生了什么。
我不知道，如果要求开发者对MqlTradeResult 结构（以交易被执行或订单被设置的时间形式） 进行补充，是否如此重要。
虽然我不明白为什么需要这样做，但我宁愿在OnTrade()中添加参数。
我不知道，如果它如此重要，请开发人员在MqlTradeResult 结构中进行补充（作为交易执行或下单的时间）。
嗯，这就是我从一开始就在问的问题 :)是否有一个先例，可以这么说 :)
如果有人在半年前就提出这个问题，我们可以希望这个功能相对快速地出现，而等待下一年--为日期输入一个变量更容易。 虽然它不会完全准确，但仍然。
虽然我不明白为什么要这样做，但我宁愿在OnTrade()中添加参数。
就我个人而言，我不能再等待贸易结构/参数的出现。我已经等了9个月了。我必须用我所得到的东西来做。
我写的是 "凭记忆"，以回应学习教科书的建议 好了，我们不要争论了，谁的理解更深刻 :)看看我对谢尔盖夫的答复。在此我重申：根据战略的逻辑，我只需要一张票和把订单带到生产的时间。你所强调的都不是。像retcode这样的 "非常重要的信息 "根本无助于优化历史上传，这就是我所说的一般情况。
1.OrderSend()和历史上传，从这一点出发，请详细说明（我不明白我们在说什么，我想我们已经没草了）。
2.从逻辑上讲，如果分析只基于OrderSend()的结果，那么行动的顺序如下
a) 检查重码，我们需要知道真正发生了什么。
b) 如果结果是成功的，获得票据、数量和价格。如果是重新报价，我们会获得新的价格（并检查它们是否令我们满意）。
c) 如果答案令人满意，而且我们没有错误，就获得一张票和时间。你可以使用服务器时间或尝试从历史记录中提取它（为了目前的近似计算，最好能知道服务器时间）。
d) 如果我们对答案不满意（或只是部分满意）--不符合数量要求或我们有重新报价，决定下一步。
PS
总而言之，无论你怎么看，都应该看一下retcode。
我不知道你在说什么，我想我们已经没有大麻了）。
看看从一开始的讨论......没有人否认retcode的重要性，但对于简单的解决方案，你可以不使用它。
这个选项对你来说有多重要？
c) 如果答案令人满意并且没有错误，我们就会得到一张票。你可以使用当前的时间。
这个选项对你来说有多重要？
这是标准选项（有其缺点，上文已提及）+自救时间。因为我不需要retcode检查，所以只有关于节省时间的问题：要么独立，要么与MqlTradeResult一起审美。实际上，这就是我提出问题的原因 :)
如果请求成功，交易迟早会出现在历史上，订单会出现在列表中。因此，你将能够查明到底发生了什么以及如何发生的。
而建议的变体可以说是 "在短时间内"，对于那些想获得我们需要的所有数据的人来说，不需要为不必要的行动而烦恼。
当然也许在响应服务器中添加其他东西，但有一些功能和原因，开发人员可能不同意这个选项（和请求，对不起没有什么理由和令人信服的论据来证实）。
PS
虽然，也许我漏掉了什么，而且开发商已经决定这很合理。