Yedelkin: Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().
そうですね、非同期の ことは考えていなかったので...。
それでは、これでおしまいです。
bool OrderSendAsync(
MqlPacketTradeRequest& packet_request, // пакетная структура запроса
);
bool OrderReceiveAsync(
MqlPacketTradeResult& packet_result // пакетная структура ответа
);
皆さん、このアイデアはいかがでしょうか？このような構造体（MqlPacketTradeResult）には、完了した注文の数などを示すフィールドを記述することができる。
皆さん、このアイデアはいかがでしょうか？このような構造体（MqlPacketTradeResult）には、完了した 注文の数などを示すフィールドを記述することができる。
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().
そうですね、非同期の ことは考えていなかったので...。
それでは、これでおしまいです。
そうですね、非同期の ことは考えていなかったので...。
さて、ここからが本題です。
非同期とは、応答を待たずに動作することを意味します。発射（OrderSenAsync）して、ターゲットに命中するかどうか試さずに、実行する。時間がないのだから。
間接的な反応としては、後で音が鳴る（OnTrade）。弾が的に当たったのかもしれないし、何かが倒れただけなのかもしれない。ここでは、ご希望に応じて、外を見る（すべての注文、取引、ポジションなどを確認する）ことができます。
そうですね、非同期の ことは考えていなかったので...。
それでは、これでおしまいです。
間接的な答えは、後から来る音（OnTrade）です。シュートがターゲットに届いたのかもしれないし、何かが落ちてきただけなのかもしれません。ここでは、希望に応じて外を見ることができます（すべての注文、取引、ポジションなどを確認できます）。
非同期とは、応答を待たずに動作することを意味します。発射（OrderSenAsync）し、ターゲットに命中するかどうか試さずに実行する。時間がないのだから。
間接的な答えとしては、後から音がする（OnTrade） - シュートが的に当たったのか、何かが落ちてきただけなのかもしれません。ここで、必要であれば外を見ることができます（すべての注文、取引、ポジションなどを確認することができます）。
非同期モード取引の経験が少ないか、そのような操作に対するMT5の機能が弱いため、間違っているのです。
非同期のための非同期は必要ないのです。そして、利益が出るときだけ使われる。例えば、ポートフォリオを取引する際、今ここで買い付けやリバランスが必要な場合。つまり、現在の価格で異なるシンボルのトレードオーダーを 十数本出すのです。
また、非同期をあなたのおっしゃるように、撮影して忘れてしまうような扱いでは、誰もやってくれません。そして、発砲に対する反応は、現在のネットポジションをベースに評価する必要がある。反応は各取引注文に固有のものである必要があります。
リダイレクトがあったのなら、そのことを教えてもらうか、別の返答をもらうべきでしょう。ネットポジションが1秒や2秒変わっていないのだから、再入札があったのかなかったのか、疑問に思ってはいけないのだ。
このディスカッションの最初のページには、ダイアグラムと受信メッセージ-イベントがあります。彼らは何もないところから現れたのではなく、長年の非同期の経験によって現れたのです。だから、そういう建築には、スキを見せずに注目する価値がある。
皆さん、このアイデアはいかがでしょうか？このような構造体（MqlPacketTradeResult）には、完了した注文の数などを示すフィールドを記述することができる。
注文のバッチは常に同じフィールドを持っていると仮定しているのですか？
IMHOでは、同じ要求のバッチはデモンストレーションのためにのみ必要で、仕事には、異なる文字、異なるボリューム、そしてもちろん異なる方向の要求を使用することになります。その結果、それぞれのレジェストを個別にチェックすることになり、まとめて送る意味がない。
そして、あなたが想定しているのは、あくまでもforループの縛りです。
アプリケーションの束には、常に同じ項目が記入されているとでも言うのでしょうか。
IMHO 同じアプリケーションのバッチは、デモのために必要なだけであり、異なる文字、異なるボリューム、そしてもちろん異なる方向のアプリケーションは、仕事で使用されるでしょう。その結果、それぞれのレジェストを個別にチェックすることになり、まとめて送る意味がない。
そして、あなたが想定しているのは、あくまでもforループの縛りです。
各レジェストを 周期的に充填することを妨げるものは何ですか？ そして、ちょうど循環的に 各結果を 処理する？
あなたの提案が唯一の既存の機能を補完する場合は、何も、それ以外の場合は、どのように単純な構造MqlPacketTradeRequest明らかではありません...
...MqlPacketTradeRequest構造体がMqlTradeRequest構造 体の動的配列の構造体である場合、単純なクエリー構造を想定したサーバーのロジックをすべて壊すことができます。
そうでなければ、端末レベルでこのバッチを別々のリクエストに分割しなければならず、この過負荷を導入した意味がなくなってしまう。