OnTradeTransaction - ページ 2 123456789 新しいコメント Vasiliy Sokolov 2015.10.20 10:45 #11 Игорь Герасько:一方では、そうですね。一方、サーバーにリクエストを送ったが、まだオペレーションが実行されていない場合はどうでしょう。注文とポジションのリスト（と口座履歴）しかない場合、どのような状態にあるのかを知ることができるのでしょうか？MT4では、すべての取引操作が同期的に行われるため、そのような問題はありません。しかし、その結果、パフォーマンスが低下してしまうのです。非同期処理の方が同期処理より速いというのは、無知から来る神話である。非同期オペレーションは、取引動作の実行サイクルが複数に分かれているのに対し、同期オペレーションは1サイクルだけです。非同期処理でもサーバーからの応答は必要ですが、交換時の実行は同じで、つまり非同期処理と同期処理の合計所要時間はほぼ同じです。非同期注文の利点は、同時に注文を出すことができること、つまり、2つ以上の注文をほぼ同時に出すことが可能なことです。これが、高速動作（トータル）を可能にしているのです。すべてのExpert Advisorで非同期送信モードが必要なわけではありません。まず、2つ以上の商品を同時に購入する必要がある様々な裁定取引や、HFTアルゴリズムに必要なものです。例えば、HFTボットはマーケットに入る ための注文を送り、3-4ミリ秒後に反対の注文を送るかもしれません。この場合、最初の注文に対するサーバーの返答を待つには時間がかかりすぎるため、非同期モードの送信-結果を待たずに送信-が必要なのです。大半のEAでは、このような速度は必要ありません。 Mikhail Filimonov 2015.10.20 14:42 #12 Vasiliy Sokolov: あなたもやり方がわからないのでは？OnTradeTransaction は特定のタスクを解決するためのサービス機能であり、あなたのように取引に使用することはできません。なぜOnTradeTransactionは保証されないのですか？」 - Expert Advisorは、あなたのようにOnTradeTransactionを通じて取引環境を構築するのではなく、システムで利用できるもの、特に注文と 取引の履歴にのみ 依存するからです。そこでオスタップは勘違いしてしまうのですが...。私に個人的な恨みがあるのなら、それを議論に持ち込む必要はないでしょうあなたが「よく知っている」技術的な問題の...強引な芝居で人を惑わせるのはお前だ! Vasiliy Sokolov 2015.10.20 15:09 #13 Михаил:そして、そこでオスタップは失敗してしまった...。私に個人的な恨みがあるのなら、それを議論に持ち込む必要はないでしょうあなたが「高度に熟練した」技術的な問題の...自己主張の強い理論で誤解を招いているだけだ! ミーシャ、やあ！ F1への旅はどうだった？ソチの天気はいかがでしたか？ Mikhail Filimonov 2015.10.20 15:23 #14 Vasiliy Sokolov: ミーシャさん、こんにちは！F1の旅はいかがでしたか？ソチの天気はいかがでしたか？こんにちは。素晴らしい海で泳いだ（水温は24度）。 Vasiliy Sokolov 2015.10.20 15:41 #15 Михаил: こんにちは。素晴らしい海で泳いだ（水温は24度）。かっこいい！とても温かいお湯ですね。真面目な話、私はあなたに対して何も不満はありません。もし、あなたがメリットを議論したいのであれば、歓迎します。しかも、誰かに教えたいという気持ちもない。みんな自分の自転車を四角い車輪で持っている。 Ihor Herasko 2015.10.20 15:49 #16 Vasiliy Sokolov:注文を送信してから次のマーケットエントリー信号までの時間が注文実行 時間を超える場合は、何もする必要がありません。このロジックは単純で、非同期オーダーを送信し、スレッドから抜け出し、そのことを忘れるというものです。次の瞬間、信号を確認するために待ちます。その時点で取引環境に変化がなければ、Expert Advisorは再び市場参入のシグナルを探し、市場参入の注文を繰り返す。逆に、すべてがうまくいって注文が執行された場合、Expert Advisorは環境分析後にポジションを持っていることを認識し、再び新しいポジションを開くことはありません。つまり、この方法では、Expert Advisorの状態が市場環境と一致することが保証 されています。高頻度取引では、注文の執行に匹敵する時間（6～100ミリ秒）の後に新しいシグナルが発生することがあり、状況はより複雑になる。この場合、ロックをしないわけにはいきません。Expert Advisor は、最後に注文を送信した時刻を記憶しておく必要があります。OnTransaction でエラーが発生した場合、ロックアウトはリセットされ、Expert Advisor は再び取引を行うことができます。多くの人が好んで祈るOnTradeTransactonは、HFTでは役に立ちませんので、注意が必要です。新規参入シグナルは、OnTradeTransaction における取引の成功に関する応答よりも速く到着する可能性があります。OnTradeTransactonを使用するしないにかかわらず、ブロッキングは必要です。OnTradeTransaction で発生するエラーはどのように制御するのですか？ エラー発生時にExpert Advisorの取引ロジックをその場でどのように 変更するのか、という反問で答えることができます。- できません。事前に適切なチェックを行わないとエラーが発生する（お金の有無、量、などなど）。しかし、一度起きてしまったことは、修正することができません。したがって、OnTradeTransaction でできる最善のことは、このエラーをログに出力し（後で Expert Advisor のロジックを修正するため）、ロックが使用されている場合はそれを削除することです。このため、OnTradeTransaction を使用する必要があります。今にミカラスの信者がやってきてトマトを投げつけるだろうが、放っておけばいい。しかし、端末の取引環境を踏まえてこそ、信頼性の高い取引ロジックが組めるのだと、私はいつも繰り返しています。それ以外は - うまくいきません。信号と信号の間の時間がどう関係するのか、よくわからないのですが？売買シグナルにはそれぞれ登録時間があります。シグナルが登録（出現）されたら、取引操作を行う必要があります。その結果、Expert Advisorはサーバーに取引注文を送信し、さらに動作します。注文はまだサーバーで実行されていない。新しいダニがやってくる。Expert Advisorは状態を再分析し、オープニングシグナルがあることを発見しますが、ワーキングオーダーの中に対応するポジション（またはオーダー）がないことを発見します。 質問：OnTrade または OnTradeTransaction からのデータを使用せずに、Expert Advisor はポジションがない理由をどのように判断できるでしょうか？いくつか理由がありそうです。1.開封要求をサーバーに送信したが、サーバーはまだ注文実行結果の回答をしていない。その答えを待つしかない。2.リクエストがまだサーバーに送信されていません。注文書を発送する必要があります。3.リクエストを送信したところ、サーバーから注文を実行できない旨の返信があった。エラーメッセージを処理し、次に何をすべきかを決定する必要があります。4.リクエストは送信されたが、サーバーが長時間応答しない（この時間は皆自分で設定する、私のは1分）（タイムアウト）。OnTradeまたはOnTradeTransactionを使用しない解決策は見当たりません。でも、あると言い張るんですね。どれがそうなのか説明してください。なぜなら、MQL4/5でスレッドロックを語るのはおかしいからです。ここには2つ以上のスレッドはなく、1つのスレッドがあるだけです。さらに、「うまくいって注文が成立した場合」などという表現で運用されていますが、どのように判断されているのか説明されていません。そして、それが私の質問の本質です。 Vasiliy Sokolov 2015.10.20 16:01 #17 Игорь Герасько:信号の発生間隔がどう関係するのか、よくわからないのですが？売買シグナルにはそれぞれ登録時間があります。信号が登録（発生）されたら、取引操作を行う必要があります。その結果、Expert Advisorはサーバーに取引注文を送信し、さらに動作します。注文はまだサーバーで実行されていない。新しいダニがやってくる。Expert Advisorは状態を再分析し、オープニングシグナルがあることを発見しますが、ワーキングオーダーの中に対応するポジション（またはオーダー）がないことを発見します。 質問：OnTrade または OnTradeTransaction からのデータを使用せずに、Expert Advisor はポジションがない理由をどのように判断できるでしょうか？いくつか理由がありそうです。1.開封要求をサーバーに送信したが、サーバーはまだ注文実行結果の回答をしていない。その答えを待つしかない。2.リクエストがまだサーバーに送信されていません。注文書を発送する必要があります。3.リクエストを送信したところ、サーバーから注文を実行できない旨の返信があった。エラーメッセージを処理し、次に何をすべきかを決定する必要があります。4.リクエストは送信されたが、サーバーが長時間応答しない（この時間は皆自分で設定する、私のは1分）（タイムアウト）。OnTradeまたはOnTradeTransactionを使用しない解決策は見当たりません。でも、あると言い張るんですね。どれがそうなのか説明してください。なぜなら、MQL4/5でスレッドロックを語るのはおかしいからです。ここには2つ以上のスレッドはなく、1つのスレッドがあるだけです。さらに、「うまくいって注文が成立した場合」などという表現で運用されていますが、どのように判断されているのか説明されていません。そして、それが私の質問の本質です。スレッドをブロックするのではなく、取引注文の 送信をブロックすることを指しています。二重の質問 ですが、Expert Advisorが取引注文を実行できない理由（市場が閉じている、資金がないなど）を判断したとしますと、次はどう するのでしょうか。Expert Advisorでどのように改善されるのでしょうか？口座にお金を追加したり、マーケットを開いたりするのでしょうか？最後の注文送信エラーの原因を知ることで、Expert Advisorのさらなる取引にどのように役立つのでしょうか。 Ihor Herasko 2015.10.20 17:03 #18 Vasiliy Sokolov:フローをブロックするのではなく、トレードオーダーの 送信をブロックすることを意味しています。ここで問題です。サーバーが注文実行エラーを返した場合、2回目の注文を送信する機能をブロック解除するには、どのようにそれを知ることができるでしょうか？ここでもOnTradeとOnTradeTransactionが使用されない場合。もう一つの質問：Expert Advisorが注文を実行できない理由（市場が閉じている、お金がないなど）を判断した場合、次はどう するのですか？Expert Advisorでどのように改善されるのでしょうか？口座にお金を追加したり、マーケットを開いたりするのでしょうか？最後の注文エラーの原因を知ることで、Expert Advisorのさらなる取引にどのように役立つのでしょうか。それはとても助けになります。資金不足は、Expert Advisor が取引注文を出す前に判断し、メッセージで（あるいは他の方法で）トレーダに通知する必要があるため、ここでは割愛します。従って、取引注文は全く送信されません。エラーメッセージは、注文の送信を継続すべきかどうかの判断材料になります。例えば、市場が閉まっている場合、すぐにリクエストを再送信する必要はない。取引をしばらく停止し（Expert Advisorの開発者が決定）、その後、新しいリクエストを送信してください（取引シグナルがまだアクティブである場合）。リクオートが発生した場合、すぐに新しいリクエストを送信することができます。ストップの設定に誤りがあった場合（ストップレベルやフリーズレベルが注文送信中に変更された）、新しいデータに従ってストップが修正され、直ちに新しいリクエストが送信されます。つまり、取引エラー（一般的にはあらゆるエラー）とその適切な処理について知ることは、あらゆる「正常な」プログラムを動作させるための前提条件なのです。 Vasiliy Sokolov 2015.10.20 17:34 #19 Игорь Герасько:ここで質問ですが、サーバーが注文実行エラーを返した場合、注文の再送信のブロックを解除するために、どのようにそれを知ることができますか？ここでもOnTradeとOnTradeTransactionが使用されない場合。とても参考になりました。資金不足は、Expert Advisor が取引注文を出す前に検知し、メッセージで（あるいは他の方法で）トレーダに通知する必要があるため、このままにしておきます。従って、取引注文は全く送信されません。エラーメッセージは、注文の送信を継続すべきかどうかの判断材料になります。例えば、市場が閉まっている場合、すぐにリクエストを再送する必要はありません。取引をしばらく停止し（Expert Advisorの開発者が決定）、その後、新しいリクエストを送信してください（取引シグナルがまだアクティブである場合）。リクオートが発生した場合、すぐに新しいリクエストを送信することができます。ストップの設定に誤りがあった場合（ストップレベルやフリーズレベルが注文送信中に変更された）、新しいデータに従ってストップが修正され、直ちに新しいリクエストが送信されます。つまり、取引エラー（一般的にはあらゆるエラー）とその正しい処理について知ることは、あらゆる「正常な」プログラムの動作に必要な条件なのです。市場が閉じている場合は、注文を出す前にこれを確認する必要があります。それ以外の場合は、取引注文を再送信する必要があります。このように、すべてのエラーは2つに分類することができます。注文を送信する前にその発生を予測できるエラー。注文を送信した時点で予測できないエラー（例：リクオート）。エキスパートアドバイザーが2番目のタイプのエラーを受け取った場合、その行動は常に同じであり、エラーのタイプに依存しません：すなわち、それはその取引注文を繰り返し、それが今度実行されることを願っています。取引注文を送信する前に、Expert Advisorは最初のタイプのエラーを制御する必要があります。したがって、Expert Advisor は OnTradeTransaction で返されるエラーの種類によって動作を修正する必要はありません。ただし、OnTradeTransaction で発生したエラーについてユーザーに通知し、前の取引が 2 番目のタイプのエラーに終わった場合、新しい取引操作の 実行時にロックをリセットすることができます。この場合、何らかの理由でOnTradeTransactionが発生しなかった場合でも、タイムアウトによってロックがリセットされるはずです。したがって、OnTradeTransactionが来るか来ないかは問題ではなく、OnTradeTransactionがあれば、繰り返しの注文が最速で執行されるだけなのです。 s.w. FreezeLevelもオーダー送信前に分析する必要があります。 Andrey Dik 2016.12.02 22:05 #20 OnTradeTransaction() で SL/TP がトリガーされたことを知るにはどうすればよいですか？ 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
一方では、そうですね。一方、サーバーにリクエストを送ったが、まだオペレーションが実行されていない場合はどうでしょう。注文とポジションのリスト（と口座履歴）しかない場合、どのような状態にあるのかを知ることができるのでしょうか？
MT4では、すべての取引操作が同期的に行われるため、そのような問題はありません。しかし、その結果、パフォーマンスが低下してしまうのです。
非同期処理の方が同期処理より速いというのは、無知から来る神話である。非同期オペレーションは、取引動作の実行サイクルが複数に分かれているのに対し、同期オペレーションは1サイクルだけです。非同期処理でもサーバーからの応答は必要ですが、交換時の実行は同じで、つまり非同期処理と同期処理の合計所要時間はほぼ同じです。非同期注文の利点は、同時に注文を出すことができること、つまり、2つ以上の注文をほぼ同時に出すことが可能なことです。これが、高速動作（トータル）を可能にしているのです。すべてのExpert Advisorで非同期送信モードが必要なわけではありません。まず、2つ以上の商品を同時に購入する必要がある様々な裁定取引や、HFTアルゴリズムに必要なものです。例えば、HFTボットはマーケットに入る ための注文を送り、3-4ミリ秒後に反対の注文を送るかもしれません。この場合、最初の注文に対するサーバーの返答を待つには時間がかかりすぎるため、非同期モードの送信-結果を待たずに送信-が必要なのです。大半のEAでは、このような速度は必要ありません。
あなたもやり方がわからないのでは？OnTradeTransaction は特定のタスクを解決するためのサービス機能であり、あなたのように取引に使用することはできません。なぜOnTradeTransactionは保証されないのですか？」 - Expert Advisorは、あなたのようにOnTradeTransactionを通じて取引環境を構築するのではなく、システムで利用できるもの、特に注文と 取引の履歴にのみ 依存するからです。
そこでオスタップは勘違いしてしまうのですが...。
私に個人的な恨みがあるのなら、それを議論に持ち込む必要はないでしょう
あなたが「よく知っている」技術的な問題の...
強引な芝居で人を惑わせるのはお前だ!
そして、そこでオスタップは失敗してしまった...。
私に個人的な恨みがあるのなら、それを議論に持ち込む必要はないでしょう
あなたが「高度に熟練した」技術的な問題の...
自己主張の強い理論で誤解を招いているだけだ!
ミーシャさん、こんにちは！F1の旅はいかがでしたか？ソチの天気はいかがでしたか？
こんにちは。
素晴らしい海で泳いだ（水温は24度）。
こんにちは。
素晴らしい海で泳いだ（水温は24度）。
かっこいい！とても温かいお湯ですね。
真面目な話、私はあなたに対して何も不満はありません。もし、あなたがメリットを議論したいのであれば、歓迎します。しかも、誰かに教えたいという気持ちもない。みんな自分の自転車を四角い車輪で持っている。
注文を送信してから次のマーケットエントリー信号までの時間が注文実行 時間を超える場合は、何もする必要がありません。このロジックは単純で、非同期オーダーを送信し、スレッドから抜け出し、そのことを忘れるというものです。次の瞬間、信号を確認するために待ちます。その時点で取引環境に変化がなければ、Expert Advisorは再び市場参入のシグナルを探し、市場参入の注文を繰り返す。逆に、すべてがうまくいって注文が執行された場合、Expert Advisorは環境分析後にポジションを持っていることを認識し、再び新しいポジションを開くことはありません。つまり、この方法では、Expert Advisorの状態が市場環境と一致することが保証 されています。
高頻度取引では、注文の執行に匹敵する時間（6～100ミリ秒）の後に新しいシグナルが発生することがあり、状況はより複雑になる。この場合、ロックをしないわけにはいきません。Expert Advisor は、最後に注文を送信した時刻を記憶しておく必要があります。OnTransaction でエラーが発生した場合、ロックアウトはリセットされ、Expert Advisor は再び取引を行うことができます。
多くの人が好んで祈るOnTradeTransactonは、HFTでは役に立ちませんので、注意が必要です。新規参入シグナルは、OnTradeTransaction における取引の成功に関する応答よりも速く到着する可能性があります。OnTradeTransactonを使用するしないにかかわらず、ブロッキングは必要です。
OnTradeTransaction で発生するエラーはどのように制御するのですか？ エラー発生時にExpert Advisorの取引ロジックをその場でどのように 変更するのか、という反問で答えることができます。- できません。事前に適切なチェックを行わないとエラーが発生する（お金の有無、量、などなど）。しかし、一度起きてしまったことは、修正することができません。したがって、OnTradeTransaction でできる最善のことは、このエラーをログに出力し（後で Expert Advisor のロジックを修正するため）、ロックが使用されている場合はそれを削除することです。このため、OnTradeTransaction を使用する必要があります。
今にミカラスの信者がやってきてトマトを投げつけるだろうが、放っておけばいい。しかし、端末の取引環境を踏まえてこそ、信頼性の高い取引ロジックが組めるのだと、私はいつも繰り返しています。それ以外は - うまくいきません。
信号と信号の間の時間がどう関係するのか、よくわからないのですが？売買シグナルにはそれぞれ登録時間があります。シグナルが登録（出現）されたら、取引操作を行う必要があります。その結果、Expert Advisorはサーバーに取引注文を送信し、さらに動作します。注文はまだサーバーで実行されていない。新しいダニがやってくる。Expert Advisorは状態を再分析し、オープニングシグナルがあることを発見しますが、ワーキングオーダーの中に対応するポジション（またはオーダー）がないことを発見します。
質問：OnTrade または OnTradeTransaction からのデータを使用せずに、Expert Advisor はポジションがない理由をどのように判断できるでしょうか？いくつか理由がありそうです。
1.開封要求をサーバーに送信したが、サーバーはまだ注文実行結果の回答をしていない。その答えを待つしかない。
2.リクエストがまだサーバーに送信されていません。注文書を発送する必要があります。
3.リクエストを送信したところ、サーバーから注文を実行できない旨の返信があった。エラーメッセージを処理し、次に何をすべきかを決定する必要があります。
4.リクエストは送信されたが、サーバーが長時間応答しない（この時間は皆自分で設定する、私のは1分）（タイムアウト）。
OnTradeまたはOnTradeTransactionを使用しない解決策は見当たりません。でも、あると言い張るんですね。どれがそうなのか説明してください。なぜなら、MQL4/5でスレッドロックを語るのはおかしいからです。ここには2つ以上のスレッドはなく、1つのスレッドがあるだけです。さらに、「うまくいって注文が成立した場合」などという表現で運用されていますが、どのように判断されているのか説明されていません。そして、それが私の質問の本質です。
信号の発生間隔がどう関係するのか、よくわからないのですが？売買シグナルにはそれぞれ登録時間があります。信号が登録（発生）されたら、取引操作を行う必要があります。その結果、Expert Advisorはサーバーに取引注文を送信し、さらに動作します。注文はまだサーバーで実行されていない。新しいダニがやってくる。Expert Advisorは状態を再分析し、オープニングシグナルがあることを発見しますが、ワーキングオーダーの中に対応するポジション（またはオーダー）がないことを発見します。
質問：OnTrade または OnTradeTransaction からのデータを使用せずに、Expert Advisor はポジションがない理由をどのように判断できるでしょうか？いくつか理由がありそうです。
1.開封要求をサーバーに送信したが、サーバーはまだ注文実行結果の回答をしていない。その答えを待つしかない。
2.リクエストがまだサーバーに送信されていません。注文書を発送する必要があります。
3.リクエストを送信したところ、サーバーから注文を実行できない旨の返信があった。エラーメッセージを処理し、次に何をすべきかを決定する必要があります。
4.リクエストは送信されたが、サーバーが長時間応答しない（この時間は皆自分で設定する、私のは1分）（タイムアウト）。
OnTradeまたはOnTradeTransactionを使用しない解決策は見当たりません。でも、あると言い張るんですね。どれがそうなのか説明してください。なぜなら、MQL4/5でスレッドロックを語るのはおかしいからです。ここには2つ以上のスレッドはなく、1つのスレッドがあるだけです。さらに、「うまくいって注文が成立した場合」などという表現で運用されていますが、どのように判断されているのか説明されていません。そして、それが私の質問の本質です。
スレッドをブロックするのではなく、取引注文の 送信をブロックすることを指しています。
二重の質問 ですが、Expert Advisorが取引注文を実行できない理由（市場が閉じている、資金がないなど）を判断したとしますと、次はどう するのでしょうか。Expert Advisorでどのように改善されるのでしょうか？口座にお金を追加したり、マーケットを開いたりするのでしょうか？最後の注文送信エラーの原因を知ることで、Expert Advisorのさらなる取引にどのように役立つのでしょうか。
フローをブロックするのではなく、トレードオーダーの 送信をブロックすることを意味しています。
ここで問題です。サーバーが注文実行エラーを返した場合、2回目の注文を送信する機能をブロック解除するには、どのようにそれを知ることができるでしょうか？ここでもOnTradeとOnTradeTransactionが使用されない場合。
もう一つの質問：Expert Advisorが注文を実行できない理由（市場が閉じている、お金がないなど）を判断した場合、次はどう するのですか？Expert Advisorでどのように改善されるのでしょうか？口座にお金を追加したり、マーケットを開いたりするのでしょうか？最後の注文エラーの原因を知ることで、Expert Advisorのさらなる取引にどのように役立つのでしょうか。
それはとても助けになります。資金不足は、Expert Advisor が取引注文を出す前に判断し、メッセージで（あるいは他の方法で）トレーダに通知する必要があるため、ここでは割愛します。従って、取引注文は全く送信されません。
エラーメッセージは、注文の送信を継続すべきかどうかの判断材料になります。例えば、市場が閉まっている場合、すぐにリクエストを再送信する必要はない。取引をしばらく停止し（Expert Advisorの開発者が決定）、その後、新しいリクエストを送信してください（取引シグナルがまだアクティブである場合）。リクオートが発生した場合、すぐに新しいリクエストを送信することができます。ストップの設定に誤りがあった場合（ストップレベルやフリーズレベルが注文送信中に変更された）、新しいデータに従ってストップが修正され、直ちに新しいリクエストが送信されます。
つまり、取引エラー（一般的にはあらゆるエラー）とその適切な処理について知ることは、あらゆる「正常な」プログラムを動作させるための前提条件なのです。
ここで質問ですが、サーバーが注文実行エラーを返した場合、注文の再送信のブロックを解除するために、どのようにそれを知ることができますか？ここでもOnTradeとOnTradeTransactionが使用されない場合。
とても参考になりました。資金不足は、Expert Advisor が取引注文を出す前に検知し、メッセージで（あるいは他の方法で）トレーダに通知する必要があるため、このままにしておきます。従って、取引注文は全く送信されません。
エラーメッセージは、注文の送信を継続すべきかどうかの判断材料になります。例えば、市場が閉まっている場合、すぐにリクエストを再送する必要はありません。取引をしばらく停止し（Expert Advisorの開発者が決定）、その後、新しいリクエストを送信してください（取引シグナルがまだアクティブである場合）。リクオートが発生した場合、すぐに新しいリクエストを送信することができます。ストップの設定に誤りがあった場合（ストップレベルやフリーズレベルが注文送信中に変更された）、新しいデータに従ってストップが修正され、直ちに新しいリクエストが送信されます。
つまり、取引エラー（一般的にはあらゆるエラー）とその正しい処理について知ることは、あらゆる「正常な」プログラムの動作に必要な条件なのです。
市場が閉じている場合は、注文を出す前にこれを確認する必要があります。
それ以外の場合は、取引注文を再送信する必要があります。このように、すべてのエラーは2つに分類することができます。
エキスパートアドバイザーが2番目のタイプのエラーを受け取った場合、その行動は常に同じであり、エラーのタイプに依存しません：すなわち、それはその取引注文を繰り返し、それが今度実行されることを願っています。取引注文を送信する前に、Expert Advisorは最初のタイプのエラーを制御する必要があります。したがって、Expert Advisor は OnTradeTransaction で返されるエラーの種類によって動作を修正する必要はありません。ただし、OnTradeTransaction で発生したエラーについてユーザーに通知し、前の取引が 2 番目のタイプのエラーに終わった場合、新しい取引操作の 実行時にロックをリセットすることができます。この場合、何らかの理由でOnTradeTransactionが発生しなかった場合でも、タイムアウトによってロックがリセットされるはずです。したがって、OnTradeTransactionが来るか来ないかは問題ではなく、OnTradeTransactionがあれば、繰り返しの注文が最速で執行されるだけなのです。
s.w. FreezeLevelもオーダー送信前に分析する必要があります。