OrderSend()问题 - 页 8

新评论
 

当我们在等待关于这个问题的文章时，我是否正确理解了贸易操作分析的一般概念。

...
bool AllowTrade = true;
ulong OrderTicket;
...
void OnTick() {
  ...
  if (!AllowTrade) return;
  ...
  MqlTradeResult Result;
  if (OrderSend(...)) {
    Ticket = Result.order;
    AllowTrade = false;
  }
}
...
void OnTrade() {
  if (AllowTrade) return;
  if (OrderSelect(Ticket)) {
    if (...)
    ...
    // AllowTrade = true|false;
  }
  else AllowTrade = true;
}
...

也就是说，大致上，在没有分析retcode的情况下发送订单后，我们在工作循环（OnTick()）中使用 "AllowTrade "标志禁止交易操作。

只有在找到订单号并对其命运做了一些分析之后，交易禁令才会在OnTrade()中解禁。

我们有两个问题。

1.在OnTrade中要检查的订单票是什么？ 在其有效期内，哪些状态是最终状态？

2.我知道Tick事件的队列（OnTick）可以 "下降"。也就是说，如果另一个Tick事件到来，而OnTick函数（来自前一个Tick）还没有完成它的工作，当前的事件将被 "放弃"，也就是说，它不会被处理。贸易事件（OnTrade）是否有类似的方法？例如，是否有可能，在主循环中，我放了一个交易禁令，而刚刚发送的订单上的OnTrade事件 "下降 "了，因为在它到达的那一刻，我仍然在处理一些与发送相应交易订单 相同的tick？

 
voix_kas: 例如，是否存在这样一种可能性，即我在主循环中放置了一个交易禁令，而刚刚发送的订单的OnTrade事件 "退出"，因为在它到达的那一刻，我仍然在处理与发送相应的交易订单 相同的tick的东西？

没有处理过这个话题，但《手册》是这样说的。

1)交易队列长度为1024个项目。如果OnTradeTransaction()处理另一个交易的时间太长，队列中的旧交易可能被较新的交易取代了。

2)OnTrade在适当的OnTradeTransaction调用之后被调用。

 
Yedelkin:

没有处理过这个话题，但《手册》是这样说的。

1)交易队列长度为1024个项目。如果OnTradeTransaction()处理另一个交易的时间太长，队列中的旧交易可能被较新的交易取代了。

2)OnTrade在适当的OnTradeTransaction调用之后被调用。

一般理解。正如papaklass 已经指出并在文章中说的https://www.mql5.com/ru/articles/232。

只有一种有保障的 方法可以找出交易账户的确切变化。这种方式是为了记住交易和交易历史的状态，并将新的状态与保存的状态进行比较。

专家顾问中还有一个服务块。:(

实际上，问题是这样的。我们能否在不分析所有变量（订单/交易/仓位）的情况下减少代码大小，而只关注从OrderSend结果中获得的订单号？或者这个数字可能是非唯一的/没有反映在历史上？

 
voix_kas: 我们能否在不分析所有变量（订单/交易/仓位）的情况下减少代码大小，而只关注从OrderSend结果中获得的订单编号？或者这个数字可能是非唯一的/没有反映在历史上？

当然了。如果一个交易请求 导致收到一张订单票，那么这张票是唯一的，订单的整个命运可以通过它来追踪。

在这里，你可以看到订单票是如何在历史中使用的：MQL5 参考 / 交易函数 / HistoryOrderGetInteger

 
Yedelkin:
当然了。如果一个交易请求 产生了一个订单票据，该票据是唯一的，可以用来跟踪订单的整个命运。
仅供参考。如果该订单没有被服务器接受执行，例如，重新报价，MqlTradeResult.order变量是否被分配了一个默认值（例如，"0"）？
 
voix_kas: 如果一个订单没有被服务器接受执行，例如，一个重新报价，MqlTradeResult变量Result.order是否被分配一些默认值（例如，"0"）？
MqlTradeResult类型的变量在使用前通常会被清零。所以，Result.order字段包含一个零值。我从来没有见过这个字段在发送交易请求 失败后有不同的值。
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:
MqlTradeResult类型的变量在被使用之前通常会被清零。所以Result.order字段包含零值。我从来没有见过这个字段在交易请求发送 失败后有不同的值。
如果你不介意的话，我想深入了解一下解释退货代码的问题。在30个申报的回复中，有24个（但愿我们不会遇到未申报的）明确表示订单投放失败。其他6个：1、TRADE_RETCODE_PLACED 假设我们不下挂单。在市场交易（SYMBOL_TRADE_EXECUTION_MARKET）中，这种反应可能吗？ 2. TRADE_RETCODE_DONE 没有什么可以进一步检查的。3.TRADE_RETCODE_DONE_PARTIAL 我认为这个答案与TRADE_RETCODE_DONE相似，因为在ORDER_FILLING_IOC模式下，如果没有挂单交易的话。TRADE_RETCODE_ORDER_CHANGED 这是否意味着毫不含糊地拒绝我们的贸易订单？ 5.TRADE_RETCODE_LOCKED 我想这是最糟糕的情况。在这种情况下，我们应该怎么做？我建议，订单号还没有出来。贸易流动很繁忙。我们无法进行贸易，也不清楚我们如何知道贸易流是否畅通。 6.TRADE_RETCODE_FROZEN 这是否意味着毫不含糊地拒绝我们的贸易订单？ 请对每个项目进行评论。
 

voix_kas: Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:  

1.TRADE_RETCODE_PLACED 假设没有挂单。在市场交易期间（SYMBOL_TRADE_EXECUTION_MARKET），该答案是否可行？

TRADE_RETCODE_DONE 没有什么可以进一步检查。一切都完全按照专家顾问的要求进行。

3.TRADE_RETCODE_DONE_PARTIAL 我假设这个答案与TRADE_RETCODE_DONE相同，因为ORDER_FILLING_IOC模式。

4.TRADE_RETCODE_ORDER_CHANGED 这是否意味着毫不含糊地拒绝了我们的贸易订单？

5.TRADE_RETCODE_LOCKED 我想这是最糟糕的情况。在这种情况下，我们应该怎么做？我建议，订单号还没有出来。贸易流动很繁忙。我们不能交易，也不清楚我们应该如何知道贸易流是否被解锁。

6.TRADE_RETCODE_FROZEN 这是否意味着毫不含糊地拒绝了我们的贸易订单？

请对每个项目进行评论。

不幸的是，我的知识不足以对每一点进行全面评论。好吧，如果发生了什么，我的同事们会纠正它。

1.论坛上曾经提到过一种情况，就是可以在一个次级经纪商那里开立交易账户。在这种情况下，子经纪人可以将交易请求进一步处理（给经纪人），并向客户终端发送TRADE_RETCODE_PLACED。经纪人最终是否会处理这样的交易请求还不得而知。

2.是的，我也这么认为。我们唯一应该记住的是，这个订单的信息将在终端数据库中以异步方式接收。

我认为我们正在讨论在ORDER_FILLING_IOC和ORDER_FILLING_RETURN 模式下部分执行交易请求的问题。

4.https://www.mql5.com/ru/forum/1111/page124#comment_18407

5.我对这个代码完全不了解。从技术上讲，事实证明，由于经纪人的一些内部原因，该请求没有被处理。以后是否会被处理还不清楚。我自己把这个代码等同于拒绝交易请求。

6.https://www.mql5.com/ru/forum/1111/page123#comment_18372

...一般来说--尝试在论坛上进行关键词搜索。你可以找到更多的信息 :)

 
Yedelkin:

不幸的是，我没有足够的知识来全面评论每一个观点。嗯，如果有的话，同事们会纠正它。

1.论坛上曾经提到过一种情况，就是可以在一个次级经纪商那里开立交易账户。在这种情况下，子经纪人可以将交易请求进一步处理（给经纪人），并向客户终端发送TRADE_RETCODE_PLACED。经纪人最终是否会处理这样的交易请求还不得而知。

2.是的，我也这么认为。我们唯一应该记住的是，这个订单的信息将在终端数据库中以异步方式接收。

我认为我们正在讨论在ORDER_FILLING_IOC和ORDER_FILLING_RETURN 模式下部分执行交易请求的问题。

4.https://www.mql5.com/ru/forum/1111/page124#comment_18407

5.我对这个代码完全不了解。从技术上讲，事实证明，由于经纪人的一些内部原因，该请求没有被处理。以后是否会被处理还不清楚。我自己把这个代码等同于拒绝交易请求。

6.https://www.mql5.com/ru/forum/1111/page123#comment_18372

...一般来说--尝试在论坛上进行关键词搜索。你可以找到更多的信息:)。

这里我们有以下情况：30个代码中的26个（包括TRADE_RETCODE_ORDER_CHANGED和TRADE_RETCODE_FROZEN）代表明确拒绝请求（不产生订单）。

TRADE_RETCODE_DONE和TRADE_RETCODE_DONE_PARTIAL - 保证创建的订单。

如何正确执行TRADE_RETCODE_PLACED（非待定）和TRADE_RETCODE_LOCKED是一个问题。希望MQ能对这两个代码提出意见。

 
这很酷，2015年大家新年快乐，但我想知道它是如何结束的。已经有两年的沉默....
123456789
新评论