このロボットでは、次のスキームでグリッドを閉じる可能性をテストしていました：損失+利益> X 、そしてそれらの両方（通常は異なるシンボルで）を閉じます。しかし、クローズしているにもかかわらず、テスターがそれに気づかず、すでにクローズしているものと既存のものを誤って「ペアリング」して次のイテレーションに進んでしまうという失敗が発生するのである。つまり、閉じた後に再計算を追加する必要があったのです。
Торговая деятельность в платформе связана с формированием и отсылкой рыночных и отложенных ордеров для исполнения брокером, а также с управлением текущими позициями путем их модификации или закрытия. Платформа позволяет удобно просматривать торговую историю на счете, настраивать оповещения о событиях на рынке и многое другое. Открытие позиций...
しかし、マクロでつまずくというのは全く同じことが書いてあります。 ただし、もちろん確認はします。
このプロジェクトの開発は、特に自分のリソースを使った言語の改良という点で、まだまだ大きな可能性を秘めています。MQLにはまだ実装されていないものが多く、動作が悪いもの（バグ）も多く、私の知る限り、開発者は言語そのものを何も改良する予定はないそうです。
マクロを処理するためには、マクロの文法を記述し、それをソースで解析し、解釈 する（各マクロの結果ソース/値を得る）という一連の処理の先頭付近で追加のレイヤーを実装する必要があるのです。これは複雑で、一部のMQLプログラマーにしか必要ないアプリケーションなので、開発はしていません。
ハッシュを使って製品の変更を識別することについては、これは解決策にはならないと思います（というか、どんなユースケースを話しているのかさっぱりわかりません）。通常、ある元ファイルが生成されてから1〜2年経たないと、その中の特定のモジュールがどのバージョンで、どのようなソース であったかを理解することはできません。そのためには、おそらくビルドプロセスをバージョン管理システムと連携させる必要があります。ハッシュ化するのはNGです。
OnTradeTransaction() で助けてください。以下のような動作は正常ですか？テスターで確認したところ、そうでした :( また、"ライブ "アカウントでは？
OnTick()には、ポジションを順番にクローズしていくループがあります。
OnTradeTrancaction()では、未決済ポジションの数を計算します。
Expert Advisor ではこのように、まずループを最後まで閉じてから、OnTradeTransaction に進み、同じ順序で計算を行います。
言い換えれば、それは
а
つまり、並列ではなく逐次的に動作するのです。
上記が正常であれば、OnTradeTransaction()は、1つの注文のみをオープン/クローズするExpert Advisorでのみ安全に使用できることが判明しました。グリッドまたはマルチシンボル・グリッドがある場合（またはマルチシンボル・グリッドがある場合：）。- は、アルゴリズムが破綻してしまいます。
ドキュメントからの引用
端末から手動で、またはOrderSend()/OrderSendAsync()関数で送信した1つの取引要求が、トレードサーバー上で複数の連続した取引トランザクションを生成することができます。さらに、これらの取引の端末 への到着順序は 保証 されていないため、ある取引取引の到着を 次々に待つという取引アルゴリズムを構築 することは できません。
その結果、すべてが計算されますが、期待された順序ではありません。
OnTradeTrancaction()でポジション数をカウントすることにした理由を教えてください。計算が正しく整理されていなければ、無駄な操作が発生する可能性は否定できません。結局のところ、ループ内で複数のポジションをクローズした場合、各ポジションをクローズした後に全てのポジションを再計算する必要はない。ループ終了後に一度だけカウントすれば十分です。または、OnTradeTrancaction()内で、IN型が設定されると数量が1増加し、OUT型が設定されると数量が減少するようにアレンジする。また、この場合でも、ポジションが完全に閉じていない場合は、それを考慮する必要があります。
OnTradeTrancaction()でポジション数をカウントすることにした理由を教えてください。
もし、あなたがすべての刻みを数えるなら - それはリソースを消費し、特にストラテジーテスターで顕著になります。トレードイベント、つまりオープンポジションのリストが実際に変更された時のみカウントする方が正しいのではないでしょうか？OnTradeTransaction()を使えば、EAへのユーザーの介入を簡単に制御することができます。(前例があります :)
このロボットでは、次のスキームでグリッドを閉じる可能性をテストしていました：損失+利益> X 、そしてそれらの両方（通常は異なるシンボルで）を閉じます。しかし、クローズしているにもかかわらず、テスターがそれに気づかず、すでにクローズしているものと既存のものを誤って「ペアリング」して次のイテレーションに進んでしまうという失敗が発生するのである。つまり、閉じた後に再計算を追加する必要があったのです。
リセットカウンターを使った再計算では、+1 / -1 ではなく、まずすべてのオープンなものに対して計算を行います。
ドキュメントからの引用
私も同意見で、当初OnTradeTransaction()を使用するのは 危険過ぎました。 実際、私はリクエストが非同期 でないケースでは拒否すると思います - それによる問題だけです。
マルチシンボルグリッドの場合、非同期が良い。だから、私なら2番目の選択肢を選びますね。
すでにその方向で考えています;)
***
このロボットでは、次のスキームに従ってグリッドを閉じる可能性をテストしました：損失+利益> X 、その後両方を閉じる（通常は別のシンボルで）。
***
この2つのポジションを正確にクローズしたいことが分かっている場合、これらのポジションのチケットを記憶し、クローズするまでクローズするのが良いでしょう（注意：whileとSleepは 不可 - クローズの命令を出し、OnTickを終了し、これらのチケットのポジションがもっとあるかどうかをチェックします - もしあれば、再度クローズを試み、OnTickを終了してください）。
この2つのポジションを正確にクローズする必要があることがわかっている場合、これらのポジションのティッカーを覚えておき、クローズするまでクローズする方が良いでしょう（注：whileやsleepは不可 - クローズの命令を出し、OnTickを終了し、これらのティッカーを持つポジションがもっとあるかどうかをチェックし、ある場合は再度クローズを試みてOnTickを終了します）。
これは貴重なアイデアです。多分、OnTick()がチケットで配列を形成し、一度閉じようとし、OnTimer()がさらにあるかどうかをチェックし、あれば閉じるのでしょう。
カチカチと音がする間に数分かかるかもしれないので、タイマにタスクを渡そう貴重なアイデアです。そうかもしれませんね。OnTick()はチケットの入った配列を生成して一旦閉じようとし、OnTimer()はチケットが残っているかどうかをチェックして、残っていれば閉じようとします。
チックとチックの間には数分かかるかもしれないので、タイマにタスクを渡してあげましょうポジションを 閉じる作業には、ALL while、Sleep、OnTimerは捨てます。次のティックでは、必要なチケットのポジションがまだ生きているかどうかをチェックし、再び注文をクローズします。
ロジックは以下の通りです。ポジションのクローズが最優先されるため、クローズループはOnTickの一番最初にあります。また、クローズチケットの配列の形成は、Tick上の任意の場所、つまり最後尾に配置することが可能です。
***
カチカチと音がする間に数分かかるかもしれないので、タイマにタスクを渡そうだから、私たちにできることは何もない。新しいティックを待つしかないのだ。
OnTick()はチケットの入った配列を生成して一旦閉じようとし、OnTimer()はチケットが残っているかどうかをチェックし、残っていれば閉じます。
別のオプション（現実の世界のために - これは最高です）は、仮想環境（完璧な実行がある）でEAを実行し、現実の世界では、仮想のものと同期することです。
だから、どうすることもできない。ただ、次のティックを待つだけだ。
例えば、ネットワークに障害が発生した場合、次のティックを待っていては、クローズする機会を逸してしまいます。
例えば、ネットワークに障害が発生した場合、次のティックを待つことは、クローズの機会を逃すことになります。
ネットワーク障害 == 断線？インターネットがなければ、何も閉じたり開いたりすることができない。どんな機会損失があるのだろう？
一般的に、取引システムがくしゃみ（接続障害など）に非常に敏感である場合 - そのような取引システムはねじ込みます。