structMqlTradeResult
{
//Очень важная информация
uint retcode; // Код результата операции//Важная информация (важна при успешном запросе)
ulong deal; // Тикет сделки, если она совершенаulong order; // Тикет ордера, если он выставлен//Малосущественная информация (важна при успешном запросе, а также в случае реквоты)double volume; // Объем сделки, подтверждённый брокеромdouble price; // Цена в сделке, подтверждённая брокером
//Малосущественная информация (важна при реквоте)double bid; // Текущая рыночная цена предложения (цены реквота)double ask; // Текущая рыночная цена спроса (цены реквота)//Не существенная информацияstring comment; // Комментарий брокера к операции (по умолчанию заполняется расшифровкой)
};
まあ、言いたいことはわかりますよね。OrderSend()関 数はブール値を返すので、念入りに確認してください。この場合、リクエストのチェックに成功すると、オーダーチケットがMqlResult構造体の変数に書き込まれます。私自身は「オーダーチケット機能の復活」と呼んでいます。以下はソースへのリンクです。「OrderSend()関数を使って購入要求を送信したとき、その要求が正常に確認されれば、作成された注文のチケットをすぐに 知ることができます。
また、モデレーター主導で話を逸らそうとするならば、同様の回答があります。MQL5チュートリアルは存在しませんし、今後も存在しないので、あなたがどのチュートリアルに目を通しているのかは不明です。 ...たぶん、議論の中身を議論するか、全く何もしないかのどちらかでしょう？:)
禁止」についての返信ありがとうございます、了解しました。
サーバーからの応答を受信したときに何が起こるかについて、正しく理解しているとは言えません。
OrderSend() は、実際にはブール値を返しますが、それは最も重要なことではありません。主なものは構造体で、サーバーからレスポンスを受け取る際に記入されます。
たしかに、構造体にチケットを書き込む（受注だけでなく、取引も）のですが、構造体の他の情報よりも重要なのでしょうか？
回答の構造を分析してみよう。私見では、おおよそ次のようなイメージです。
追記
構造体の正しい名称はMqlResultではなくMqlTradeResult です（私見ではあまり重要ではありませんが）。
要求が正しく、実行された場合、ボリュームと価格は、サーバーがトランザクションのデータパラメータを減らすために "権利を持っていた "とそれは、サーバーのアクションにExpert Advisorの反応を必要とするかもしれない場合に重要である。
残念ながら、まだ理解できていません。
何らかの理由で、return 構造に「時間」フィールドが必要な場合、表示される順番に時間を使用します。これだけで、小さな歴史をコントロールすることができるのです。
この構造体は、MqlResultではなく 、MqlTradeResultと 呼ばれるべきです（私の意見では、それは本当に重要ではありません）。
サーバーからレスポンスを受け取ったときのことを正しく理解しているわけではありません。
OrderSend() は確かにブール値を返しますが、それは最も重要なことではありません。 主要なことは、サーバーからの応答を受け取ることによって満たされる構造体です。
たしかに、チケットは構造体に書き込まれる（注文だけでなく、取引も）が、構造体の他の情報よりも重要なのだろうか？
"OrderSend() "関数で買いリクエストを送信すると、リクエストが正常にチェックされたときに作成された注文のチケットをすぐに知る ことができます。しかし同時に、注文そのものがまだクライアント端末に表示されていない場合もあり、OrderSelect関数で選択しようとすると失敗 します。第2文から、そのチケットがわかっても、オーダー特性（オーダータイム）で作業できるとは限らないことがわかる。したがって、「出てきた順番に時間を使う」というのは、理想的な解決策ではありません。また、注文が「全く開かない」こともあります。私のアプローチでは、履歴に入る前の注文がどうなったかに関係なく、小さな履歴をコントロールすることで問題を解決します。
そんなに重要なら、MqlTradeResultの 構造体に（取引が実行された時間や注文が設定された時間という形で） 追加するよう開発者に頼んでみてはどうでしょう。
なぜ必要なのか理解できないが、むしろOnTrade()にパラメータを追加したい。
そんなに重要なことなら、MqlTradeResultの 構造（取引が成立した時間や注文を行った 時間）を追加するように開発者に依頼すればいいのでは？
まあ、最初からそういうことを聞いていたのですが......)いわば前例があったのでしょうか :)
追記：半年前にこの質問をする人がいれば、次の年を待ちながら、比較的早くこの機能の登場を期待できるかもしれません。 日付の変数を入力するのは簡単です。完全に正確ではなくなりますが、それでもです。
なぜ必要なのか理解できないが、むしろOnTrade()にパラメータを追加したい。
個人的には、Tradeの構造・パラメータの登場がもう待ち遠しいです。もう9カ月も待っているんですよ。今あるもので、なんとかやっていくしかない。
教科書を勉強した方がいいというアドバイスに対して、「記憶で」と書いたのですが まあ、どっちが理解力があるかなんて議論はやめましょうよ :)セルゲイエフへの返信を見てください。繰り返しになりますが、戦略のロジックでは、チケットと生産にかかる時間だけが必要なのです。あなたが強調したのは、そのどちらでもありません。retcodeのような "非常に重要な情報 "は、履歴のアップロードの最適化には全く役立たない、というのが一般的な話です。
1.OrderSend()と履歴のアップロード、ここから先は詳しくお願いします（何を言っているのか理解できず、草臥れそうです）。
2.論理的には、OrderSend()の結果のみに基づいて 解析する場合、一連の動作は以下のようになります。
a) リコードを確認し、実際に何が起こったかを知る必要があります。
b) 結果が成功した場合、チケット、数量、価格を取得する。再見積もりの場合、新しい価格を入手し、それが満足のいくものであるかどうかを確認します。
c) 回答が満足のいくもので、エラーがない場合は、チケットと時間を取得します。サーバー時刻を使うか、履歴から引き出してみるか（現時点でのおおよその計算には、サーバー時刻がわかっていたほうがよい）。
d) 回答に満足できない場合（または部分的にしか満足できない場合） - ボリュームと一致しない、または再見積もりがある場合、次のステップを決定します。
追記
要するに、どう考えても、レトコードは見るべきものなのだ。
何を言っているのかわからないし、雑草が切れているような気がする）。
最初から議論を見てください。 ...誰もretcodeの重要性を否定しているわけではありませんが、単純な解決策であれば、retcodeなしでも大丈夫です。
このオプションはあなたにとってどの程度重要なのでしょうか？
c) 回答が満足のいくもので、エラーがなければ、チケットを取得する。現在の時刻を使用することができます。
このオプションはあなたにとってどの程度重要なのでしょうか？
これは、標準オプション（上記の デメリットがあります）＋セルフセービングタイムです。リコードチェックは必要ないので、単独で、あるいはMqlTradeResultと一緒に美的に、時間を節約することだけが問題です。実は、これが私の質問の理由です :)
リクエストが成功すれば、遅かれ早かれ取引は履歴に残り、注文はリストに表示されるようになります。その結果、何がどのように起こったのかを正確に知ることができるようになるのです。
そして、提案されたバリエーションは、必要なデータをすべて取得し、不必要なアクションを煩わせたくない人のための、いわば「急場しのぎ」です。
もちろん、多分応答サーバーで他の何かを追加しますが、開発者がこのオプション（と要求、申し訳ありませんが少し正当化し、説得力のある引数によって確認）に同意しないかもしれない理由と機能の数があります。
追記
もっとも、私が見落としているだけで、開発者がかなり合理的と判断しているのかもしれませんが。