voix_kas: Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:
このテーマの記事を待っている間、私はトレードオペレーション分析の一般的な概念を正しく理解しているのでしょうか。
すなわち、大雑把に言えば、retcodeを解析せずに注文を出した後、ワークループ(OnTick())内で "AllowTrade "フラグを使って売買操作を禁止しているのです。
取引禁止は、注文番号が判明し、その運命がある程度分析された後、OnTrade()で初めて解除されます。
2つの質問をさせていただきます。
1.OnTradeで確認するオーダーチケットとは何ですか? そのライフタイムで最終的にどのステータスになるのでしょうか?
2.Tickイベント(OnTick)のキューが「落ちる」ことがあるのは知っています。つまり、別のTickイベントが到着し、(前のTickの)OnTick関数がまだ処理を終えていない場合、現在のイベントは「ドロップ」されます、つまり、処理されません。トレードイベント(OnTrade)でも同様のアプローチが可能でしょうか?つまり、例えば、メインループで取引禁止にして、送信したばかりの注文の OnTrade イベントが「ドロップ」することは可能でしょうか?なぜなら、そのイベントが到着した時点では、対応する取引注文の 送信と同じティックでまだ何かを処理中であるためです。
このトピックを扱ったことはありませんが、ハンドブックには次のように書かれています。
このトピックを扱ったことはありませんが、ハンドブックには次のように書かれています。
一般的に理解されている。papaklass さんが既に指摘され、記事で言われているようにhttps://www.mql5.com/ru/articles/232。
取引口座で何が変更されたかを正確に知るための 確実な 方法はただ一つです。その方法は、取引の状態や取引履歴を記憶し、新しい状態と保存した状態を比較することです。
Expert Advisorのサービスブロックがもう一つ。:(
実は、問題はこれなんです。すべての変数(注文/取引/ポジション)を解析せず、OrderSendの結果から得られる注文番号のみに着目してコードサイズを小さくできないでしょうか。あるいは、この数値は非一意である/履歴に反映されていないのではないか?
もちろんです。取引依頼の 結果、オーダーチケットを受け取った場合、このチケットは一意であり、オーダーの全運命をこのチケットでたどることができる。
ここでは、履歴で注文チケットがどのように使用されるかを見ることができます:MQL5リファレンス / 取引関数 / HistoryOrderGetInteger
もちろんです。取引依頼が 注文チケットになった場合、そのチケットは一意であり、注文の全行程を追跡するために使用することができます。
MqlTradeResult型の変数は、通常、使用される前にゼロにされます。そのため、Result.orderフィールドには値がゼロとなります。取引要求の送信に 失敗した後、このフィールドが別の値を取るのを見たことがない。
voix_kas: Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:
1. TRADE_RETCODE_PLACED 保留注文がないものとする。マーケット取引(SYMBOL_TRADE_EXECUTION_MARKET)中にこの回答は可能でしょうか?
TRADE_RETCODE_DONE これ以上確認することはできません。全てはExpert Advisorの要求通りでした。
3.TRADE_RETCODE_DONE_PARTIAL ORDER_FILLING_IOCモードを考えると、TRADE_RETCODE_DONEと同じ回答だと思われるのですが、いかがでしょうか。
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
...そして一般的には、フォーラムのキーワード検索を試してみてください。他にもいろいろな情報がありますよ :)
残念ながら、各ポイントについて十分にコメントできるほどの知識はありません。まあ、どちらかというと、同僚が訂正してくれるでしょう。
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を正しく実行するにはどうしたらよいのかが問題です。この2つのコードについて、MQからのコメントをお願いします。