真剣に約定拒否対策に乗り出すにあたり、
ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy.
について調べました。
■発生理由
複数EAを同時に運用する場合、EAのオーダー処理の競合が大きな問題になってきます。
MT4では、複数のオーダーを
同時に発注することができないからです。
そして、その時にエラーメッセージとして表示されるのが
ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy.
です。
MT4上で運用される複数のEAは、まるで同時処理されている様に見えますが、
実際の所プログラムはあくまで順番に処理されており、
もし前の順番のEAの処理が残っていれば、次のEAに障害が出ます。
それが最も顕著なのが、注文処理です。
一つのEAによって発生した注文処理は、メタトレーダーを通してブローカーとのやりとりを行いますが、
その間に別のEAからオーダーが入ると、後から発注されたオーダーは処理されず、エラーとなってしまうのです。
ちなみに、そもそも『文脈エラー』って何だよ！？
と思ってしまいますが、ここでのコンテクストは、『文脈』と訳すのではなく、
『競合する存在』と解するのが正しいようです。
Wikipediaより情報工学におけるコンテキストは、デバイスが使われている状況を意味する。例えばある時点でデバイスを使用しているユーザーなど。コンテキストアウェアネスおよびコンテキストスイッチを参照されたい。
■対処
繰り返しになりますが、
ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy.
こいつが出ているということは注文が通っていません。
別のEAの注文によってメタトレーダーとブローカーがやりとりを行っている最中だからです。
これを避ける手段は注文処理が終わるのを待つ以外ありません。
ですから、EAのコード内で、
今現在 ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy. が発生するような状態なのか、
注文の競合が起こる状態なのか。という事を事前にチェックした上で、競合するようならば
しばらく待機してから発注をかける必要があります。
このチェックを行う関数が、
IsTradeAllowed()
です。
こいつは、返り値がbool型の関数で、
今はどんな注文も入ってないからチャンスだよ！って時は、
IsTradeAllowed()=true
今は前のオーダーの注文処理中だからエラーんなるよ！って時は、
IsTradeAllowed()=false
となります。
詳しくはこちら。
http://articles.mql4.com/141英語なので大変ですが、
このエラーの発生理由から様々なケースの対処法とそのコードまでとても詳しく書かれています。
僕は英語得意じゃないので途中まで読んで嫌になりました。
ですから、ここから先の具体的対処法は、例によって愛読書
FXメタトレーダー実践プログラミング (現代の錬金術師シリーズ)
FXメタトレーダー入門―最先端システムトレードソフト使いこなし術
を参考にしたものです。
対処� �whileループを使う方法注文が約定するまで、ひたすらwhileループでオーダーをかけ続ける方法です。
延々と146 Trade context is busy.が出続けるでしょうが、そんなもの何回出ようが知ったことではありません。
とにかく約定するまで繰り返し続けます。
注意点は2つ。再注文を出すまで何秒間待機させるかきちんと設定しておくことと、
無限ループに陥らないよう、ループの脱出に気を使うことです。
これは
ERR_OFF_QUOTES 136 Off quotes.
ERR_BROKER_BUSY 137 Broker is busy.
ERR_REQUOTE 138 Requote.
らの約定拒否対策にも使えますので、詳しくは近いうちに書きたいと思います。
対処�◆ー，�tickまで待たせる方法�，鉾罎戮襪噺�果は限定的ですが、コード自体はこっちの方が簡単です。
int start()
{
if(IsTradeAllowed() == false) return(0);
.....
}
という感じでメイン関数を呼び出した直後に注文可能であるか判断し、
このEAの注文を受ける準備ができていなければ、 return(0)によってメイン関数（start()）を終了します。
これだけです。
MT4の仕様上、次回start()が呼び出されるのは次のtickが更新されたときになるので、
その時には恐らく注文処理は終了していることでしょう。
ただしこの方法は、一回の動作で一つの注文しか行わないEAでしか使えない方法です。
というのも、ContextBusyの発生原因である前回注文の処理は必ずしも別EAの注文によっておこるわけではなく、
実際の発生は、同一EAが発注したオーダー処理が続いているという場合のほうが遙かに多いからです。
例えば、“保有している全ポジションについてmodifyをかける”、“保有している全ポジションを一斉決済する”場合などです。
何度もループを回してオーダーをかけるのですから、busyになるのも分かります。
この様な場合については、EAの動作初めにしかチェックを行わない�△諒�法ではうまくいきません。
start()の直後でIsTradeAllowed()によるチェックを行うのではなく、
やはり注文を連続する関数などの中で逐一、IsTradeAllowed()を行う必要があります。
つまり�，諒�法でなんとかする必要があるわけです。
実は、
僕は窓埋めEAについては�△諒�法を用いて競合処理を行っていました（一回の動作で一つしか注文をしないからです）。
しかし決済時にでしつこく発注をかけ続ける必要性が出てきてしまいましたので、
結局決済については�，諒�法を用いて約定エラー対策を行うことになってしまいました。
面倒くさかったです。
ちなみに、上記愛読書（FXメタトレーダー実践プログラミング）の212ページ以降に
ブローカー対策を考慮した発注例（プログラム例）がしっかり載っていました。
僕完全に読み飛ばしちゃってたよ。もっと早く気づけば楽できたのに・・
