OrderSend() の質問 - ページ 8

 

このテーマの記事を待っている間、私はトレードオペレーション分析の一般的な概念を正しく理解しているのでしょうか。

...
bool AllowTrade = true;
ulong OrderTicket;
...
void OnTick() {
  ...
  if (!AllowTrade) return;
  ...
  MqlTradeResult Result;
  if (OrderSend(...)) {
    Ticket = Result.order;
    AllowTrade = false;
  }
}
...
void OnTrade() {
  if (AllowTrade) return;
  if (OrderSelect(Ticket)) {
    if (...)
    ...
    // AllowTrade = true|false;
  }
  else AllowTrade = true;
}
...

すなわち、大雑把に言えば、retcodeを解析せずに注文を出した後、ワークループ(OnTick())内で "AllowTrade "フラグを使って売買操作を禁止しているのです。

取引禁止は、注文番号が判明し、その運命がある程度分析された後、OnTrade()で初めて解除されます。

2つの質問をさせていただきます。

1.OnTradeで確認するオーダーチケットとは何ですか? そのライフタイムで最終的にどのステータスになるのでしょうか?

2.Tickイベント(OnTick)のキューが「落ちる」ことがあるのは知っています。つまり、別のTickイベントが到着し、(前のTickの)OnTick関数がまだ処理を終えていない場合、現在のイベントは「ドロップ」されます、つまり、処理されません。トレードイベント(OnTrade)でも同様のアプローチが可能でしょうか?つまり、例えば、メインループで取引禁止にして、送信したばかりの注文の OnTrade イベントが「ドロップ」することは可能でしょうか?なぜなら、そのイベントが到着した時点では、対応する取引注文の 送信と同じティックでまだ何かを処理中であるためです。

 
voix_kas: つまり、例えば、メインループで取引禁止を置き、今送信した注文のOnTradeイベントが到着するまでに、対応する取引注文の 送信と同じティックでまだ何かを処理しているため、「ドロップアウト」する確率があるのでしょうか?

このトピックを扱ったことはありませんが、ハンドブックには次のように書かれています。

1)トランザクションのキューの長さは1024個ですOnTradeTransaction()が別の取引を処理するのに時間がかかりすぎると、キュー内の古い取引が新しい取引に取って代わられる可能性があります。

2)OnTrade は適切な OnTradeTransaction 呼び出しの後に呼び出さ れる。

 
Yedelkin:

このトピックを扱ったことはありませんが、ハンドブックには次のように書かれています。

1)トランザクションのキューの長さは1024個ですOnTradeTransaction()が別の取引を処理するのに時間がかかりすぎると、キュー内の古い取引が新しい取引に取って代わられる可能性があります。

2)OnTrade は適切な OnTradeTransaction 呼び出しの後に呼び出さ れる。

一般的に理解されている。papaklass さんが既に指摘され、記事で言われているようにhttps://www.mql5.com/ru/articles/232。

取引口座で何が変更されたかを正確に知るための 確実な 方法はただ一つです。その方法は、取引の状態や取引履歴を記憶し、新しい状態と保存した状態を比較することです。

Expert Advisorのサービスブロックがもう一つ。:(

実は、問題はこれなんです。すべての変数(注文/取引/ポジション)を解析せず、OrderSendの結果から得られる注文番号のみに着目してコードサイズを小さくできないでしょうか。あるいは、この数値は非一意である/履歴に反映されていないのではないか?

 
voix_kas: すべての変数(注文/取引/ポジション)を解析せず、OrderSendの結果から番号を取得した注文のみに着目し、コードサイズを小さくすることは可能でしょうか。あるいは、この数値は非一意である/履歴に反映されていないのではないか?

もちろんです。取引依頼の 結果、オーダーチケットを受け取った場合、このチケットは一意であり、オーダーの全運命をこのチケットでたどることができる。

ここでは、履歴で注文チケットがどのように使用されるかを見ることができます:MQL5リファレンス / 取引関数 / HistoryOrderGetInteger

 
Yedelkin:
もちろんです。取引依頼が 注文チケットになった場合、そのチケットは一意であり、注文の全行程を追跡するために使用することができます。
ご参考までに。注文がサーバーに受け入れられず実行されなかった場合(例:リクオート)、MqlTradeResult.order変数にデフォルト値(例:"0")が割り当てられますか?
 
voix_kas: 注文がサーバーに受け入れられなかった場合(例:リクオート)、MqlTradeResult変数Result.orderに何らかのデフォルト値(例:"0")が割り当てられますか?
MqlTradeResult型の変数は、通常、使用する前にゼロにされます。そのため、Result.orderフィールドにはゼロの値が含まれています。取引要求の送信に 失敗した後、このフィールドが別の値を取るのを見たことがない。
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:
MqlTradeResult型の変数は、通常、使用される前にゼロにされます。そのため、Result.orderフィールドには値がゼロとなります。取引要求の送信に 失敗した後、このフィールドが別の値を取るのを見たことがない。
もしよろしければ、返品コードの解釈の問題をさらに深く掘り下げたいのですが、申告された30件のうち24件(未申告に遭遇しないことを祈ります)は、明らかに発注の失敗を表しています。他の6つ:1.TRADE_RETCODE_PLACED 仮に、保留の注文を入れないとします。マーケット取引(SYMBOL_TRADE_EXECUTION_MARKET)でこの応答は可能か? 2. TRADE_RETCODE_DONE これ以上確認できない。3. TRADE_RETCODE_DONE_PARTIAL ORDER_FILLING_IOC モードで、保留中の注文がない場合、この答えは TRADE_RETCODE_DONE に似ていると推測されます。TRADE_RETCODE_ORDER_CHANGED 取引注文の拒否を意味するのでしょうか?TRADE_RETCODE_LOCKED 最悪のケースだと思います。この場合、どうしたらいいのでしょうか?注文番号がまだ出ていないことを提案します。貿易の流れは忙しい。貿易ができないし、貿易の流れが遮断されていないことをどうやって知ることができるのか不明である。TRADE_RETCODE_FROZEN これは我々の取引注文を明確に拒否するという意味ですか? 各項目についてコメントをお願いします。
 

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

...そして一般的には、フォーラムのキーワード検索を試してみてください。他にもいろいろな情報がありますよ :)

 
Yedelkin:

残念ながら、各ポイントについて十分にコメントできるほどの知識はありません。まあ、どちらかというと、同僚が訂正してくれるでしょう。

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からのコメントをお願いします。

 
かっこいいですね、みなさんあけましておめでとうございます!#2015ですが、どんな風に終わったんでしょうね。沈黙の2年でしたね...。