FORTS: OnTradeTransaction() 返回代码

Sergey Chalyshev 2015.11.26 17:56 #81

Михаил:

你误解了。

是服务器在20秒内没有发送订单状态 PLASED。

我是指服务器开发人员。

Andrey Khatimlianskii 2015.11.26 23:31 #82

Михаил:

在终端有一个明显的错误，ORDER_STATE_STARTED 订单状态 "挂起"。

它最终被整理出来了吗？

交易所对这一命令究竟 是怎么说的？放置的速度快吗？如果是这样，显然是服务器或MT终端出现了错误，没有更新状态。有了这个，你就可以去找服务台了。

MQ Alexander 2015.11.27 08:39 #83

由于在服务台与迈克尔讨论的问题。

显然，我们需要解释订单系统是如何运作的，以及安置意味着什么。

所以。

1.您发送一个请求

buy limit 5.00 SNGR-3.16 at 35501

2.MT5服务器检查此请求（参数、预交易等）。如果有问题，你会得到一个响应请求的相应错误代码。

之后，您创建了一个新的订单，给它一个票据（#24025010）--这样，该订单的状态就被设定为 "开始"。订单票据用于在交易所下单时，将MT5中的订单标识符与交易所的订单联系起来。
终端在 "开始 "状态下发送一个关于添加新订单的交易，这可以在OnTradeTransaction中跟踪。

3.接下来，交易服务器（通过网关）将您的订单发送给交易所，如果请求成功发送，您的请求将收到一个响应--这意味着
"请求已经发送"，结果将以异步方式执行，因为您事先不知道交易所将在多长时间内作出答复。

在这一点上，你可以看到日志中的记录

2015.11.26 10:48:23.726 Trades  'xxxxxx': buy limit 5.00 SNGR-3.16 at 35501 placed for execution in 7 ms

4.一段时间后，交易所在其系统中设置订单，为其分配一个标识符，然后通知网关和MT5服务器。
如果交易所设置了订单，订单标识符将被写入MT5的订单中，订单状态将随着=>放置而改变。
如果交易所因某种原因拒绝下单，那么该订单将被删除。

所有这些都可以通过简单地记录进入OnTradeTransaction的交易来进行跟踪。

================================================================================

会发生什么。

1.你提交一个订单请求--见步骤1-3。

2.当订单已经在MT5中，而它还没有出现在交易所的时候，你发送一个订单来撤回这个订单。
但由于这个订单处于初始状态（开始），而且没有定义它的订单的存在，你会收到拒绝撤回订单的通知
。

你需要在你的EA的逻辑中进行适当的检查-修正。

Z.U. 另一件事是，在一秒钟之内。

2015.11.26 10:48:24.583 Trades  'xxxxxx': failed cancel order #24025010 buy limit 5.00 SNGR-3.16 at 35501.00000 [Invalid request]

(此外还有20秒)，订单应该已经下了，这个问题正在处理中，其中一个潜在的问题已经被发现--我们正在改正。

[删除] 2015.11.27 08:45 #84

MQ Alexander:

谢谢你的解释!请将此添加到文档中!

Yury Kirillov 2015.11.27 12:54 #85

MQ Alexander:

由于在服务台与迈克尔讨论了这个问题。

显然，我们需要解释订单系统是如何运作的，以及安置意味着什么。

所以。

1.您发送一个请求

2.MT5服务器检查此请求（参数、预交易等）。如果有问题，你会得到一个响应请求的相应错误代码。

之后，您创建了一个新的订单，给它一个票据（#24025010）--这样，该订单的状态就被设定为 "开始"。订单票据用于在交易所下单时，将MT5中的订单标识符与交易所的订单联系起来。
终端在 "开始 "状态下发送一个关于添加新订单的交易，这可以在OnTradeTransaction中跟踪。

3.接下来，交易服务器（通过网关）将您的订单发送给交易所，如果请求成功发送，您的请求将收到一个响应--这意味着
"请求已经发送"，结果将以异步方式执行，因为您事先不知道交易所将在多长时间内作出答复。

在这一点上，你可以看到日志中的记录

4.一段时间后，交易所在其系统中设置订单，为其分配一个标识符，然后通知网关和MT5服务器。
如果交易所设置了订单，订单标识符将被写入MT5的订单中，订单状态将随着=>放置而改变。
如果交易所因某种原因拒绝下单，那么该订单将被删除。

所有这些都可以通过简单地记录进入OnTradeTransaction的交易来进行跟踪。

================================================================================

会发生什么。

1.你提交一个订单请求--见步骤1-3。

2.当订单已经在MT5中，而它还没有出现在交易所的时候，你发送一个订单来撤回这个订单。
但由于这个订单处于初始状态（开始），而且没有定义它的订单的存在，你会收到拒绝撤回订单的通知
。

你需要在你的EA的逻辑中进行适当的检查-修正。

Z.U. 另一件事是，在一秒钟内

(此外，20秒）应该下单，我们正在处理，我们已经发现了一个潜在的问题 - 让我们来解决它。

我们仍然不明白，在什么时候订单的状态 "开始 "变成了 "放置 "的状态。这种情况是根据你的解释中的第3点发生的，还是根据你的解释中的第4点发生的，或者在第3点和第4点两种情况下都发生？

Andrey Khatimlianskii 2015.11.27 15:49 #86

Yury Kirillov:
不清楚在什么时候订单的状态从 "开始 "变为 "放置"。这种情况是根据你的解释中的第3点发生的，还是根据你的解释中的第4点发生的，或者在第3点和第4点两种情况下都发生？

MQ Alexander:

4.一段时间后，交易所在其系统中设置订单，分配其标识符，然后通知网关和MT5服务器。
如果交易所设置了订单 - 订单标识符被写入MT5中的订单，订单状态从开始=>放置。

Andrey Khatimlianskii 2015.11.27 15:51 #87

MQ Alexander:

3.然后，交易服务器（通过网关）将您的请求发送到交易所，如果请求被成功发送，那么您的请求将被回复，这意味着

"该请求已被发送"，其工作结果将被异步执行，因为你事先不知道交换的响应时间是什么。

因此，正是在这一点上，你在日记分录中看到

2015.11.26 10:48:23.726 Trades  'xxxxxx': buy limit 5.00 SNGR-3.16 at 35501 placed for execution in 7 ms

4.一段时间后，交易所在其系统中设置订单，为其分配一个标识符，然后通知网关和MT5服务器。
如果交易所设置了订单，MT5中订单的标识符将被写入订单中，订单状态将随着=>放置而变化。

这里有另一个引起混淆的原因：在日志中，它说订单已经下了，但事实上它的状态还没有改变。

也许我们应该写 "发送 "而不是 "下达"，因为订单实际上还没有被交易所接受？

Mikhail Filimonov 2015.11.27 17:45 #88

结果是这样的。

在对一个订单进行任何操作之前（或之后）。

你必须每次都 "检查 "它的状态（如果我不确定，请纠正我）。

enum ENUM_ORD_REAL_STATE
{
  ORD_NOT_SPECIFIED         = 0, //Состояние ордера не определено
  ORD_NONE_CANCELED         = 1, //Ордера нет, отменён пользователем
  ORD_NONE_PARTIAL_CANCELED = 2, //Ордера нет, исполнился частично (не был залит вторым объёмом)
  ORD_NONE_PARTIAL          = 3, //Ордера нет, исполнился частично
  ORD_NONE_EXPIRED          = 4, //Ордера нет, удалён по сроку
  ORD_NONE_FILLED           = 5, //Ордера нет, исполнился полностью
  ORD_NONE_REJECTED         = 6, //Ордера нет, отклонён брокером(биржей)
  ORD_BUSY                  = 7, //Ордер находится в переходном состоянии
  ORD_EXIST                 = 8, //Ордер выставлен на биржу, возможны действия над ним
  ORD_EXIST_PARTIAL         = 9  //Ордер выставлен на биржу, частично исполнился, возможны действия над ним
};
//
ENUM_ORD_REAL_STATE CheckOrderState( const ulong ticket )
{
  if ( ticket > 0 )
  {
    if ( HistoryOrderSelect( ticket ) ) //Только не существующий ордер может находится в истории
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( HistoryOrderGetInteger( ticket, ORDER_STATE ) );
      double init_volume = HistoryOrderGetDouble( ticket, ORDER_VOLUME_INITIAL );
      double cur_volume = HistoryOrderGetDouble( ticket, ORDER_VOLUME_CURRENT );
//---      
      switch( ord_state )
      {
                                                           
        case ORDER_STATE_CANCELED:       if ( init_volume == init_volume )
                                         {
                                           return( ORD_NONE_CANCELED );
                                         }
                                         else
                                         {
                                           return( ORD_NONE_PARTIAL_CANCELED );
                                         }  
                                         break;
                                         
        case ORDER_STATE_PARTIAL:        return( ORD_NONE_PARTIAL );
                                         break;
                                         
        case ORDER_STATE_EXPIRED:        return( ORD_NONE_EXPIRED );
                                         break;
                                                                              
        case ORDER_STATE_FILLED:         return( ORD_NONE_FILLED );
                                         break;
                                         
        case ORDER_STATE_REJECTED:       return( ORD_NONE_REJECTED );
                                         break;   
 
       
      }
    }
    else
    if ( OrderSelect( ticket ) ) 
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( OrderGetInteger( ORDER_STATE ) );
//---      
      switch( ord_state )
      {
        case ORDER_STATE_STARTED:
        case ORDER_STATE_REQUEST_ADD:
        case ORDER_STATE_REQUEST_MODIFY:
        case ORDER_STATE_REQUEST_CANCEL: return( ORD_BUSY );
                                         break; 
 
        case ORDER_STATE_PARTIAL:        return( ORD_EXIST_PARTIAL );
                                         break;
                                          
        case ORDER_STATE_PLACED:         return( ORD_EXIST );
                                         break;
      }
    }
  }
  return( ORD_NOT_SPECIFIED );
}

Sergey Chalyshev 2015.11.27 18:53 #89

Михаил:

结果是这样的。

在对一个订单进行任何操作之前（或之后）。

你必须每次都 "检查 "它的状态（如果我错过了什么，请纠正我）。

错了。

如果我们看一下HistoryOrderSelect( 票)，那么我们需要应用HistoryOrderGetInteger(),HistoryOrderGetDouble()

Mikhail Filimonov 2015.11.27 19:07 #90

Sergey Chalyshev:

不正确。

如果我们看一下HistoryOrderSelect( 票)，我们需要应用HistoryOrderGetInteger(),HistoryOrderGetDouble()。

对，这是一个误印 :)

谢谢你，纠正了...

FORTS: OnTradeTransaction() 返回代码 - 页 9