FORTS: OnTradeTransaction() のリターンコード - ページ 6

新しいコメント
 

すごい!

インストール時間 - 15:07:31.849

削除時刻 - 15:07:31.865

そして、Invalid requestも もう25週目、真面目にやって ます。サービスデスクが沈黙している理由がわかりました。


 

その場合、アドバイザーはコードを受け取ることができます。

TRADE_RETCODE_REJECT
 

セルゲイ！

結果的に正解でしたね。MQバグ

端末が注文状況を更新しない。

2015.11.26 15:41:56.094 Forts_trader (GAZR-12.15,H1)    Remove: Ордер не отослан! Причина: Неправильный запрос; Билет = 24041883
2015.11.26 15:41:56.094 Forts_trader (GAZR-12.15,H1)    DEBUG: order state = ORDER_STATE_STARTED
2015.11.26 15:41:56.068 Forts_trader (GAZR-12.15,H1)    CheckOrders: Sell ордер установлен. Билет = 24041883

注文を受けたが、状態がORDER_STATE_STARTEDの ままになっている

 
Михаил:

セルゲイ！

結果的に正解でしたね。MQバグ

端末が注文状況を更新しない。

注文を受けたが、状態がORDER_STATE_STARTEDの ままである。

マイケル、これらのメッセージの後にも注文は存在するのでしょうか？ひょっとして、数ms前に取引が成立していたのでは？

 
Alexey Kozitsyn:

マイケル、これらのメッセージの後にも注文は存在するのでしょうか？ひょっとして、取引が成立しなかったのは、数ms前だったのでしょうか？

はい、エラー後も注文は存在します。

削除（変更）する前に、注文が存在するかどうかチェックされるため、問題ではありません。

void COrder::Remove()
{
  if ( ticket > 0 )
  {
    if ( OrderSelect( ticket ) )
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( OrderGetInteger( ORDER_STATE ) );
      if ( ( ord_state == ORDER_STATE_REQUEST_MODIFY ) ||
           ( ord_state == ORDER_STATE_REQUEST_CANCEL ) ||
           ( ord_state == ORDER_STATE_REQUEST_ADD ) ) return;
//........................................ Other code 
   }
  }
}
 

なぜかというと、こんな事情があるんです。

ログブック（専門家）。

2015.11.26 18:05:16.725 FROG (RTS-12.15,M1)     TradeRemoveCycle case ORDER_STATE_PLACED: ОШИБКА #4756,  retcode = 10013. Ордер не удален!
2015.11.26 18:05:16.691 FROG (RTS-12.15,M1)     TradeRemoveCycle: ORDER_STATE_PLACED

注文が受理 された（つまり処理できる）ことはわかるのですが、要求がおかしいのです。

ログブックでは、このように記録されている。

2015.11.26 18:05:16.725 Trades  '1007642': failed cancel order #35817112 buy 0.00  at market [Invalid request]
2015.11.26 18:05:16.693 Trades  '1007642': cancel order #35817112 buy limit 1.00 RTS-12.15 at 87780
2015.11.26 18:05:16.691 Trades  '1007642': deal #4375646 buy 1.00 RTS-12.15 at 87780 done (based on order #35817112)

つまり、注文が削除された瞬間に、その注文に対して取引が実行されたことになります。そして、ロボットはもう存在しない注文を削除しようとしている。

今、どうしようか悩んでいるところです。

 
Михаил:

はい、エラーの後に注文が存在します。

しかし、削除（変更）する前に、その注文が存在するかどうかチェックされるので、問題にはなりません。

ご覧の通り、私のもそうです...。
 
Alexey Kozitsyn:

なぜかというと、こんな事情があるんです。

ログブック（専門家）。

注文が受理 された（つまり処理できる）ことはわかるのですが、要求がおかしいのです。

ログブックでは、このように記録されている。

つまり、注文が削除された瞬間に、その注文に対して取引が実行されたことになります。そして、ロボットはもう存在しない注文を削除しようとしている。

今、どうしたらいいか悩んでいます。

私もこの問題に悩まされましたが、解決しました。

OrderSend()やOrderSendAsync()はどのようなコマンドで設定するのでしょうか？

 
Михаил:

私もこの問題はありましたが、解決しました。

OrderSend()とOrderSendAsync()のどちらを設定するコマンドでしょうか？

OrderSend()。そして、この場合、何が違うのでしょうか？
 
Alexey Kozitsyn:
注文送信(OrderSend)

注文が実行されているときは、その実行を制御しないので、OnTick()やOnBookEvent()をブロックしないことです。

OnTradeTransaction()で取引イベントを処理し、実行される注文を 迅速に制御する必要があります。

近々、やり方のコードを掲載する予定です...。

1234567891011
新しいコメント