OrderSendAsync()関数 - ページ 7

[削除済み]

コントロールできない非同期＝カオス。

非同期制御はOnTrade()の中でしか行えません。

OnTrade()で特定のリクエストを識別する必要性がある。

したがって、OrderSendAsync()は、サーバーから受け取ったチケットの番号を返さなければならないことになります（タイムアウトの状況を除く）。チケット番号は、サーバーとクライアントの両方からリクエストを一意に識別するために必要です。

このメカニズムを統一することによって、OrderSend()関数も 再設計することができます - チケット番号、またはサーバーへのオーダー送信に失敗した場合には"-1 "を返すようにします。

そして、プログラム中に、生成されたチケットのリストを持つクラスを実装します。

各OnTrade()イベントで、理解する。

1. これが我々の行動なのか、それとも例えばExpert Advisorの別のインスタンスの行動なのか（magesは不要になります）。

2.どのような要求に対して、どのような回答を得ているか。

[TheXpert]

voix_kas:

したがって、OrderSendAsync()は、サーバーから受信したチケット番号を返す必要があります（タイムアウトの状況を除く）。チケット番号は、サーバーとクライアントの双方でリクエストを明確に識別するために必要です。

こんにちは。非同期って知ってる？

[Denis Kirichenko]

TheXpert:
こんにちは。非同期が何なのか知っているのか？

<<同期非同期を忘れろ>>。

[Renat Fatkhullin]

現在、OnTradeResult(MqlTradeResult&info)関数の追加を検討しており、サーバーの応答に関する正確な詳細を持つことになります。

[Mykola Demko]

Renat:
現在、サーバーレスポンスの正確な詳細を持つOnTradeResult(MqlTradeResult&info) 関数の追加を検討中です。

私見ですが、ユーザー側からはこのように見えるはずです。

の場合、ユーザーはポインターを扱うクラスを作成し、それにトレードシグナル処理のクラスをアタッチします。

シグナルが発生すると、新しいオブジェクトが生成され、サーバーにリクエストが送信されるため、シグナルが実行されるまでオブジェクトが存在する。

OnTradeは運命を監視し、決定を下す（どちらか一方）か、新しいリクエストを送るか、あるいはやり過ごしたオブジェクトを破棄します。

この方式では、このトレードイベントの起動に関連して、どのオブジェクトを処理するのかを特定する必要がある。

[TheXpert]

Urain:

このスキームでは、このトレードイベントの起動に関連して、どのオブジェクトを処理するかを特定する必要があります。

何が問題なのか？

[Mykola Demko]

TheXpert:
何が問題なのか？

冗談だろう？

貿易は今や顔が見えないので、到着したリストの中のどのオブジェクトを処理すべきなのかがわかりません。

[TheXpert]

Urain:

冗談だろう？

そんなことはありません。ちなみに、OnTradeでは100％来ないので、わざわざやる価値はあまりありません（MT4のエラー1と同じぐらいです）

というか、やっぱり保険に入らないとダメなんですね。

良いものにする」のが良いのではないでしょうか？

[Mykola Demko]

TheXpert:

そんなことはありません。ちなみに、OnTradeは100％来ないので、わざわざやる価値はあまりない（MT4のエラー1と同じぐらい）です

というか、やっぱり保険に入らないとダメなんですね。

良いものにする」のが良いのではないでしょうか？

トレードが〜100％入らない理由を正当化する？

[TheXpert]

Urain:
トレードが〜100％入らない理由を正当化する？

なぜなら、壊れたパケット、ドロップされた接続などのくだりがあるからです。信頼性がない。頼りない......立ち直るしかない。