MT5でOrderSendを正しく動作させる方法 - ページ 10

 
prostotrader:

使ってみてください。

これは良い例です。しかし、ここで気になることがあります。OnTradeTransaction()が注文処理時のデータを返さない場合はどうすればよいですか?まあ、何らかの形で失われているのかもしれませんね。サーバーは送信したが、端末は受信していない。送信された注文の100%について必要な数のOnTradeTransaction()関数 コールが得られ、すべての取引報告が端末に到達することはどの程度保証されていますか(主にTRADE_TRANSACTION_REQUESTのトランザクションに興味があります)。

なぜなら、もしこの応答がなければ(例えば接続が切れたために)フラグをクリアせず、すべてが立ち上がってしまうからです。

 
fxsaber:

確認はしていませんが、もしかしたらOrderSendの後、すべてのEAがOnTradeTransactionに対応するイベントを取得するのかもしれません。

そうすれば、松葉杖なしで、同じシンボル上の複数のEAについて、すべてが解決されます。

確認しました!そういうものなんだ!
 
Oleg Shenker:

これは良い例です。しかし、ここで気になることがあります。OnTradeTransaction() が注文処理データを返さない場合はどうなりますか?まあ、何らかの形で失われているのかもしれませんね。サーバーは送信したが、端末は受信していない。送信された注文の100%について必要な数のOnTradeTransaction()関数 コールが得られ、すべての取引報告が端末に到達することはどの程度保証されていますか(主にTRADE_TRANSACTION_REQUESTのトランザクションに興味があります)。

なぜなら、もしこの応答がなければ(例えば接続が切れたために)、私はフラグを削除せず、すべてはそのままにしておくからです。

OnTradeTransactionのイベントが発生しないことが何度かありました。

そこで、0.5秒周期のタイマーを使って注文の状態をチェックする関数を作りました。

この実装はExpert Advisorの一般的なコードを複雑にしていますが、インターネット上で作業する場合、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秒のタイマーを使ってオーダーの状態をチェックする関数を書きました。

この実装はExpert Advisorの一般的なコードを複雑にしていますが、インターネット上で作業する場合、100%の保証はありません。

すべてが規則正しく進むように。

によって追加されました。

ここでチェックすることを思いつきました

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

取引ごとに特別な魔法のコードを作って、開かれた扉を突破しようとしているように思える。注文を一意に識別するための order_id が存在する。

それとも、私が的外れなことを言っているのでしょうか?

 
Oleg Shenker:

この人は、トレードごとに特別な魔法のコードを作って、開かれた扉を突破しているような気がします。注文を一意に識別するために使用できる order_id がある。

それとも、私が的外れなことを言っているのでしょうか?

はい、order_idはありますが、残念ながらOnTradeTransactionに イベントが来ないことがあります。

(個人的に何度か食べました)。

そして、order_idをどこに "put "するか?

によって追加されました。

ここで、今日はサーバーの応答遅延が発生しました

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で イベントが来ないことがあります。

(個人的に数回食べました)。

order_idをどこに "stuff "するか?

によって追加されました。

ここで、今日はサーバーの応答遅延が発生しました

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

3つの命令が送られ、その記録がログにはっきりと残っている。その後、関数 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だけが、プリンターが立つ内部に入ることができる......というわけです。

ヘルプデスクはまず、私が2つの同じEAを立ち上げていると説得し始めました(ログから判断すると、明らかに同じチャートに立っています)。そして、「お前は馬鹿だ、コードの誤りを直せ」と言われました。

要するに、彼らに言わせれば、それはあり得ないことなのだ。しかし、ログを見ると、明らかに4回来ている。

 
prostotrader:

はい、order_idはありますが、残念ながらOnTradeTransactionで イベントが来ないことがあります。

(個人的に数回食べました)。

order_idをどこに "stuff "するか?

によって追加されました。

ここで、今日はサーバーの応答遅延が発生しました。

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:

はい、注文が履歴に残らない場合があるためです(保留注文など)。

によって追加されました。

そして、あなたは間違ったコードを持っています

そこはどうしたんですか?2行のコードでどれだけの間違いを犯すことができるか。

 
Oleg Shenker:

そこで何が問題なのか?2行のコードでどれだけの間違いがあるか。

2つではなく、1つです :)

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

TRADE_TRANSACTION_REQUESTは、OrderSendAsymcを 使用してオーダーチケットを取得する際に必要です。