如何在MT5中正确使用OrderSend? - 页 10

 
prostotrader:

使用它。

这是一个很好的例子。但我有一个问题。如果OnTradeTransaction()没有返回订单处理的数据怎么办?嗯,他们可能以某种方式丢失了。服务器已经发送,但终端没有收到。有多少能保证我对100%发送的订单获得所需数量的OnTradeTransaction()函数调用,并且所有的交易报告都能到达终端(我主要对transaction.type = TRADE_TRANSACTION_REQUEST感兴趣)。

因为如果我没有得到这个回应(例如因为连接中断),我就不会清除这个标志,一切都会站起来。

 
fxsaber:

我没有检查过,但也许在OrderSend之后,所有的EA都会得到OnTradeTransaction的相应事件。

然后,一切都解决了,不需要拐杖,对同一符号的多个EA也是如此。

检查了!这就是事实!
 
Oleg Shenker:

这是一个很好的例子。但这里有一个问题困扰着我。如果OnTradeTransaction()不返回订单处理数据怎么办?嗯,他们可能以某种方式丢失了。服务器已经发送,但终端还没有收到。有多少能保证我对100%发送的订单获得所需数量的OnTradeTransaction()函数调用,并且所有的交易报告都能到达终端(我主要对transaction.type = TRADE_TRANSACTION_REQUEST感兴趣)。

因为如果我没有得到这个回应(例如因为连接中断),我就不会删除标志,一切都会成立。

我有好几次OnTradeTransaction事件没有发生。

因此,我写了一个函数,用一个周期为0.5秒的定时器来检查订单的状态。

该实施方案使专家顾问的一般代码复杂化,但在互联网上工作时没有100%的保证。

一切都会像时钟一样运行。

由以下人员添加

我有了在这里检查的想法

https://www.mql5.com/ru/blogs/post/557544

Отслеживание ордера, после команды OrderSendAsync
Отслеживание ордера, после команды OrderSendAsync
  • 2015.04.29
  • Mikhail Filimonov
  • www.mql5.com
Отслеживание ордера, после команды OrderSendAsyncМихаил | 23 апреля, 2015В статье рассказывается принцип отслеживания ордера после команды OrderSendAsync, если нет события TradeTransaction...
 
prostotrader:

我有好几次,OnTradeTransaction事件没有发生。

因此,我写了一个函数,用一个周期为0.5秒的定时器来检查订单的状态。

该实施方案使专家顾问的一般代码复杂化,但在互联网上工作时没有100%的保证。

一切都会像时钟一样运行。

由以下人员添加

我有了在这里检查的想法

https://www.mql5.com/ru/blogs/post/557544

在我看来,这家伙似乎是想通过为每笔交易创造特殊的神奇代码来突破一扇敞开的大门。有一个order_id,一个订单可以被唯一地识别。

还是我没听清?

 
Oleg Shenker:

在我看来,这家伙是通过为每个交易创造特殊的魔法代码来突破一扇敞开的大门。有一个order_id,可以用来唯一地识别订单。

还是我没听清?

是的,有一个order_id,但不幸的是,有时事件并没有出现在OnTradeTransaction 中。

(我个人曾有过几次这样的经历)。

然后在哪里 "放置 "订单_ID?

由以下人员添加

这里,今天有一个服务器响应延迟

2016.12.28 14:04:56.442  (MXI-3.17,M1)  CheckOrders: Задержка ответа сервера. Ожидание продолжается...
2016.12.28 14:04:56.443  (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
 
prostotrader:

是的,有一个order_id,但不幸的是,有时事件不在OnTradeTransaction 中出现。

(我本人也有过几次这样的经历)。

那么在哪里 "塞 "入订单_id呢?

由以下人员添加

这里,今天有一个服务器响应延迟

2016.12.28 14:04:56.442  (MXI-3.17,M1)  CheckOrders: Задержка ответа сервера. Ожидание продолжается...
2016.12.28 14:04:56.443  (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...

有一天,我有一个不同的 "挡板"。

2016.12.23 15:04:02.865 TriArbTrader_8-4 (EURGBP,H1)    1111 DealSell           3 orders are sent.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction EURUSD Position is closed in 59699 mksec.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction EURUSD Position is closed in 59712 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction GBPUSD Retcode = 10009. Slippage = 1379.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction GBPUSD Position is closed in 127691 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction All reposts are checked. Direction = 0
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction Unexpected transaction request.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction EURGBP Retcode = 10009. Slippage = -40993.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction EURGBP Position is closed in 1339448077 mksec.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1)    1111 OnTradeTransaction All reposts are checked. Direction = -1

我发了三份订单,在我的日志里有明确的记录。之后,函数OnTradeTransactions() TRADE_TRANSACTION_TYPE被调用了4次。

函数代码以检查开始。

void OnTradeTransaction(const MqlTradeTransaction& transaction,
                        const MqlTradeRequest&     request,
                        const MqlTradeResult&      results)
   {
    if(transaction.type == TRADE_TRANSACTION_REQUEST && request.action == TRADE_ACTION_DEAL)
      {
       if(request.magic == ExpertMagic)
         {

也就是说,只有带有自己的专家印章的TRADE_TRANSACTION_REQUIEST可以进入里面,在那里,印刷商站在那里。

服务台首先开始劝说我,我有两个相同的EA站在那里(从日志来看,显然是在同一个图表上)。然后他们说:"你是个傻瓜,修正代码中的错误"。

简而言之,按照他们的说法,这是不可能的。但日志清楚地显示,该事件来了四次。

 
prostotrader:

是的,有一个order_id,但不幸的是,有时事件不在OnTradeTransaction 中出现。

(我本人也有过几次这样的经历)。

那么在哪里 "塞 "入订单_id呢?

由以下人员添加

在这里,今天我有一个服务器响应延迟。

2016.12.28 14:04:56.442  (MXI-3.17,M1)  CheckOrders: Задержка ответа сервера. Ожидание продолжается...
2016.12.28 14:04:56.443  (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...

无论如何,我还是不明白为什么我们不能按股票代码搜索订单?检查我们发送的订单中有哪些没有进入TradeTransaction是非常容易的。然后就看一下历史上有这张票的订单状态。

虽然,订单历史只显示状态为FILLED的订单。

 
Oleg Shenker:

而且仍然不清楚为什么订单不能按股票代码进行搜索?毕竟,很容易检查哪个订单没有来到TradeTransaction。然后就看一下历史上有这个代号的订单的状态。

虽然,当我亲自尝试时,在订单历史中,只有状态为FILLED的订单。

是的,因为该订单可能不在历史记录中(待定订单,等等)。

添加

而你的代码是错误的

 
prostotrader:

是的,因为该订单可能不在历史记录中(待定订单,等等)。

由以下人员添加

而你的代码是错误的

那里出了什么问题?在两行代码中,你能犯多少个错误。

 
Oleg Shenker:

那里有什么问题吗?两行代码中可以有多少错误。

不是两个,是一个 :)

if(transaction.type == TRADE_TRANSACTION_REQUEST && request.action == TRADE_ACTION_DEAL)

当你使用OrderSendAsymc 获得订单票时,需要TRADE_TRANSACTION_REQUEST。

原因: