受注サイクルの整理
MT4でMQL5ライブラリを起動 するというテーマで継続中
#property strict // https://www.mql5.com/ru/docs/standardlibrary/graphics/cgraphic #include <Graphics\Graphic.mqh> // MQL5\Include\Graphics\Graphic.mqh void OnStart() { double Y[] = {1, 2}; GraphPlot(Y); }
テスターでは、スピードスライダーを31にすると遅く、32にすると超高速でテストが急展開することがよくあります。
コードにカウンターを介したディレイを挿入することで、それを乗り切っています。
input int gDelay = 10000; // Счетчик для задержки, off=0 void OnTick() { int delayCount = 0; while(delayCount < gDelay) ++delayCount; }
入力による遅延は、EAの速度やプロセッサーの能力によって調整することができます。
スピード32では、自分の好きなスピードでポイントに移動できるようになりました。
以下では、MT4だけでなく、MT5と他のプラットフォームにも関係する話題に触れていきます。しかし、ロジックは認識しやすいようにMQL4で書く予定なので、このブランチでは。
注文の変更・削除のバックボーン（注文の肉）は、ほとんどの場合、以下のロジックに帰着します。
// Самый распространенный костяк логики модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration());
今、そのアプローチはまれだが、はるかに正しい
// Редкий, но правильный костяк модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration())) { i = OrdersTotal(); // Хотя бы так // А лучше так // OnTick(); break; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно) }
取引注文の 送信後は取引環境が変化するため、取引サーバーからの返信後、直ちにTSの全取引ロジックを一から実行することをお勧めします。
今、このアプローチは珍しいが、ずっと正しい
このバリエーションは、任意のエラーでリストの最後の順序を変更することにフックし、1つ以上の順序を持っているExpert Advisorは、他のすべての「失明」。
私のレシピ：そのすべての注文をループし、それぞれを処理し（必要なら処理前に市場情報を更新）、次のティックで、次のアプローチを行う。場合によっては、現在のループが終了した直後に次のアプローチ（OnTickコール）が行われることがありますが、これはループ内にエラーがあった場合です。
このオプションは、何らかのエラーが発生した場合、リストの最後の注文の修正をループし、1つ以上の注文を持つEAが他のすべての注文を「見失う」ようにします。
この条件のため、ループは発生しない
if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration()))
私の処方箋：すべての注文をループさせ、それぞれを処理し（必要なら処理前にマーケット情報を更新）、次のティックで、次のアプローチを行います。場合によっては、現在のループにエラーがあった場合、そのループが終了した直後に次のアプローチ（OnTickコール）を行うことができます。
その後、端末のログに取引要求の エラーがさらに表示されるようになりました。
この場合、1つの注文も変更され（例えば、価格の後ろに引き上げられる）、他の注文は長時間放置される可能性が あるからです。
この論理は最初からおかしいのです。私たちは意識的に選択しなければなりません。実際の注文が1つである方が良いのか、それとも無関係な注文がたくさんある方が良いのか。
私のレシピはまだ有効です。
これは出ませんでしたね。
OrderModify を 5 秒間実行させる。その実行中に、トレードサーバー上で部分指値注文が複数回実行され、十数回の取引が発生するとします。
このロジックは、最初から何かが間違っているのです。1つの実際の注文が良いか、多くの無関係な注文が良いかを意識的に選択する必要があります。
1つのオーダーが同時に異なるレベルになることはありません。それとも、レベルごとに異なるEAを用意したほうがいいのでしょうか？これは、大半の戦略にとって疑問の残る解決策です。
特殊なケースとして、複数のポジション（複数のエントリーでトレンドにより獲得）とそれに対するトレーリングストップを設定。1つの取引だけSLを引くのか、それとも全部を修正するのか？急な動きとそれに続く急なロールバックでは、1つの注文だけを修正するオプションは多くを失うことになります（OnTickへの新しい呼び出しがそれぞれリストの一番最初の注文を修正するので、残りを得ることはできません）。
OrderModify を 5 秒間実行します。その実行中に、取引サーバー上で部分指値注文が数回実行され、数十件の取引が発生したとする。
と仮定します。約定した（はずの）注文をすべて処理し、次のティックまたは最初のサイクルの直後の新しい注文に渡します。
そうでなければ、最後の1つの注文の、最後の1つの実行された部分を扱うリスクを常に負うことになるのです。おそらく一番小さい部分です。大量の注文を放置してぶら下げること。
1つのオーダーが同時に異なるレベルになることはありません。それとも、レベルごとに異なるEAを用意したほうがいいのでしょうか？これは、大半の戦略にとって疑問の残る解決策です。
特殊なケースとして、複数のポジション（複数のエントリーでトレンドにより獲得）とそれに対するトレーリングストップを設定。1つの取引だけSLを引くのか、それとも全部を修正するのか？もし、急な動きとそれに続く急な戻りがあった場合、1つの注文だけを修正するオプションは多くの損失をもたらします（OnTickへの新しい呼び出しはそれぞれリストの一番最初の注文を修正するので、残りの注文に到達することはありません）。
OnTickが1つのオーダーだけを変更する理由がわからないのですが？すべて修正されます。
と言ってみましょう。処理された（はずの）注文をすべて処理し、次のティックまたは最初のサイクルの直後に新しい注文に移行します。
そうでなければ、常に最後の1つの注文の、最後の1つの実行された部分を扱うリスクを負うことになります。おそらく一番小さい部分です。大量の注文を放置してぶら下げること。
バックボーンという言葉に注目しています。ロット優先選択などの形で肉付けはいつでもできる。一方、コアロジックは変わらず、取引注文が 成功した後、取引ロジック全体をゼロから実行します。
OnTickが1つの注文だけを変更する理由がわからないのですが？すべて修正されます。
なぜなら、価格は移動し、OnTickを新たに呼び出すたびに、同じ、リストの最初の、注文を新たに修正するための条件が満たされるからです。特に、5秒間の修正であれば、なおさらです ;)
バックボーン」という言葉に注目してください。ロット優先選択などの形で肉はいつでも追加できる。一方、コアロジックは変わらず、取引注文が 成功した後、すべての取引ロジックをゼロから実行します。
このような「バックボーン」は、複数の注文を扱うEAのロジックを壊してしまうことになります。
1つのオーダーを持つシステムには何のメリットもなく、他をスポイルすることになるなら、何の意味があるのでしょうか？
注文を処理する前に、数量および/または価格からの距離でソートするのは良い解決策です。しかし、フォーラムからコードをコピーした人が全員それを実装してくれるとは思わない方がいい。
その意味では、私のコードの方が安全です。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索