Взаимодействие клиентского терминала и торгового сервера для проведения операций постановки ордеров производится посредством торговых запросов. Запрос представлен специальной предопределенной структурой MqlTradeRequest, которая содержит все поля, необходимые для заключения торговых сделок. Результат обработки запроса представлен структурой...
Глобальные переменные создаются путем размещения их объявлений вне описания какой-либо функции. Глобальные переменные определяются на том же уровне, что и функции, т. е. не локальны ни в каком блоке. Область видимости глобальных переменных - вся программа, глобальные переменные доступны из всех функций, определенных в программе...
このトピックについて伝えたくないのは私ではなく、このトピックの本質を理解していないのです。
あなたは、私が遅延クエリのそれぞれのタイプに独自のソリューションが必要であることを 理解していないと決めつけています。すべてのリクエストにはそれぞれの特性があり、共通の解決策は不可能です。オーダーのための1つの解決策は1つの解決策であり、あるデータの繰り返しのリクエストのための別の解決策です。過去2回の記事で、私たちは注文に対する解決策に取り組んでいます。次の記事もそれについてです。私の意見は、長すぎるということです。
保留中のリクエストの解決に3つの記事、そのうちの2つは何も完結していない......。実際には（形ではなく）、保留中の注文リクエストの解決策は非常に簡単です。
あなたは、私が保留中のクエリーの種類ごとに異なる解決策が必要であることを 理解していないと判断した。すべてのクエリにはそれぞれの特性があり、共通の解決策は不可能です。オーダーのための解決策は1つであり、あるデータを繰り返し要求するための解決策は別のものです。この2つの記事では、注文に対する解決策に取り組んでいます。次の記事もそれについてです。私の意見は、長すぎるということです。
保留中のリクエストの解決に3つの記事、そのうちの2つは何も完結していない......。実際には（形ではなく）、保留中の注文リクエストの解決は非常に簡単です。
不可能」という部分は少し性急だ。
その通り、それは不可能だ。異なるオブジェクト・クエリ - 異なるプロパティ。1つのクエリオブジェクトにすべてのプロパティを入れることはできない。
単純な作業を3つの記事で1ヶ月半も解決できるのが不思議でならない。このプログラミング方法が「効率的」と見なされるのであれば、私は別のプログラミングをしていてよかったと思う。
サーバーへのEAコールをすべてトレースすることは不可能だ。
明らかに）失敗した注文を繰り返し送信するという問題に対する解決策は、複雑さを必要とせず、単純に解決できるからです。
もし注文がライブラリーのメソッドを使って送信されないので あれば、すべての取引ロジックは独立して記述されなければなりません。ライブラリはこのようなことをしない機会を提供しますが、ライブラリの機能によってすべてを行うことを強制するわけではありません。
このような状況では、ライブラリは自身のものではない取引機能を管理することはできません。しかし、サードパーティの機能を通じて送信された取引要求が 成功した事実を報告することはできます。
サーバーから返されたエラーとその適切な処理に反応するライブラリーの機能を使用して ください。
サーバーのリターンコードのハンドラーとして何が考えられますか？
その通り、不可能だ。異なるクエリオブジェクト、異なるプロパティ。1つのオブジェクト・クエリにすべてのプロパティを挿入することはできません。
単純な作業を1ヶ月半かけて3つの記事で解決するのはどうかと思う。このプログラミング方法が「効率的」と見なされるのであれば、私は別のプログラミングをしていてよかったと思う。
オブジェクトは保留中のトレード リクエストである。取引依頼に関するすべての情報は、すべての依頼に対して単一の構造体（MqlTradeRequest）に格納されます。
荒らしですか？
実際、私はコンセプトを説明しています。ステップ・バイ・ステップです。私は自分で文章を書き、3、4回間違いがないかチェックする。私は記事の中でコンセプトの内容、ロジック、機能性を声に出し、どうすればできるかを示す。同時に、様々な選択肢を事前に考え、その大部分はゴミ箱に捨てられる。すべてのコードをゼロから、異なる原則に従って完全に書き直すこともある。それからテスターとデモですべてをテストする。そして、いくつかのバグを見逃して、次の記事で修正する。
もしそのコードが初回から動いたら、それは爆弾が埋まっているということであり、将来大きな驚きがあることを期待している。
1時間ですべてを自分で書いてしまうとは驚きです。チェックもせず、テストもせず、とにかく動けばいいんです。）
あなたが何を単純だと考えているのか、本当に理解したい。これは、ライブラリの他の部分の将来の機能の一部であり、事前のすべては、まだ存在しないが計画されているものと「あなたの頭の中で」リンクされるべきであることを、なぜ理解しようとしないのですか？
私は、一度だけやって浮遊させるというタスクは設定しない。私には別の仕事がある--すべてのものをさらにどう相互に結びつけていくかを考え抜くことだ。それには時間と一定のアプローチが必要です。それが難しいなら...。それなら複雑ですね。
...
サーバーのリターン・コード・ハンドラーはどうなっていますか？
簡単で効果的な解決策をお見せしましょう。
1.グローバル変数 Del_reqを宣言する；
2.void Delayed_request()関数を書く。この関数はOnTimer()から1秒に1回呼び出される（Del_req != NULLの場合）。
3.パラメータ int delayed_request_ID = 0 を、注文を送信する各取引関数に追加する。
4.各取引リクエストはサーバーレスポンスを返します。delayed_request = 0 (Delayed_request() からの繰り返し呼び出しではない) で、サーバー応答が要求の繰り返しを必要とする場合、取引関数はすべての呼び出しパラメータを Del_req 変数に書き込み (delayed_request_ID と parameters の 2 つのセパレータを使用)、行の最後に必要な試行回数 (たとえば 10) を追加します。
5.Delayed_request()関数は、1秒に1回Del_req文字列をチェックする。文字列がNULLでない場合、関数はそれを配列に入れ、それをループして呼の 部分文字列を見つけ、それを見つけ、全体の文字列からそれを抽出し、それを 分割し、呼のタイプを調べ、delayed_request_IDとともに必要なトレード関数に パラメータを渡す。次に、呼カウンタを調べ、1つデクリメントする。1減算してカウンタがゼロの場合、Del_req文字列全体から呼の部分文字列 全体を消去する。
6.トレード関数がdelayed_request_IDを持つ呼を受け入れ、サーバーへの要求が成功した場合、共通のDel_req文字列から呼の部分文字列を消去する(delayed_request_IDで見つける)。
この作業は1日で完了し、トレード・リクエストだけでなく、あらゆるリクエストに適用できる。
成熟したプログラマーにとって、単純な解決策が自明でないことに本当に驚いています。
短時間で効果的な解決策を紹介しよう。
1.グローバル変数、 文字列Del_reqを宣言する；
2.void Delayed_request()関数を書く。この関数はOnTimer()から1秒に1回呼び出される。
3.注文を送信する各取引関数に、パラメータ int delayed_request_ID = 0 を追加する。
4.各取引リクエストはサーバー応答を返します。delayed_request = 0 (Delayed_request() からの繰り返し呼び出しではない) で、サーバー応答が要求の繰り返しを必要とする場合、取引関数はすべての呼び出しパラメーターを Del_req 変数に書き込み (delayed_request_ID とパラメーターの 2 つの区切り文字を使用)、行の最後に必要な試行回数 (例: 10) を追加します。
5.5.Delayed_request()関数は、1秒に1回Del_req文字列をチェックする。文字列がNULLでない場合、関数はそれを配列に入れ、それをループして呼を見つけ、総文字列からそれを抽出し、それを分割し、呼のタイプを調べ、delayed_request_IDとともに必要なトレード関数にパラメータを渡す。次に、呼カウンタを調べ、それを1つデクリメントする。カウンタが0でない場合、Del_reqは呼文字列の呼カウンタを1つ小さい値に変更し、0である場合、全Del_req文字列から呼文字列全体を消去する。
6.トレード関数がdelayed_request_IDを持つ呼を受信し、サーバーへの要求が成功した場合、Del_req文字列全体から呼の部分文字列を消去する(delayed_request_IDで検索する)。
これはすべて1日で実行でき、トレード・リクエストだけでなく、あらゆるリクエストに適用できる。
ZY.荒らしではありません。成熟したプログラマーにとって単純な解決策が自明でないことに本当に驚いています。
メソッドにわざとブレーキをかけるのか？
そして、提案された方法と何が違うのか？文字列を扱うという高価な関数を通して作業しなければならないという事実を除けば？概念的には何もない。だから、意図したとおりになるのだ。さらに、今行われていることは、あなたはまだ知らないが、遅延クエリを扱う機能を拡張するために使われる。
意識的にブレーキを踏む？
そして、提案されているメソッドと何が違うのか？文字列を扱う高価な関数をこなさなければならなくなることを除けば？何もない。だから、意図したとおりになるのだ。さらに、今行われていることは、あなたはまだ知らないだろうが、遅延クエリを扱う機能を拡張するために使われるのである。
好きなようにやってください。それがあなたの創造性です。私は自分の意見を述べた。
そして、ブレーキはない。保留中のリクエストは依然として1秒に1回送信される。
違いは、保留中のリクエストは本格的なオブジェクトにならないため、その背後に多くのコードを引っ張らないことだ。
好きなようにやればいい。あなたの芸術だ。私は意見を述べた。
それにブレーキはない。保留中のリクエストはとにかく1秒に1回送られる。
なぜ1秒に1回送られるのか？取引サーバーに殺到させるため？
保留中のクエリーが本格的なオブジェクトにならないため、多くのコードを引きずらない点が異なる。
そして、私がさらに計画していることを実装するためには、一人前のオブジェクトが必要なのだ。しかし、あなたはまだそのことを知らず、さらなる作業のために課題のごく一部を解決する非効率的な方法を提供しようとしている。そして、ここではすべてが連動しており、一般的なコンセプトは同じです-将来計画されている他のことも、この小さな部分に依存しています。
とにかく、あなたの意見に感謝する。どんな意見でも役に立つし、理にかなっている。
そして、そうだね。次のタスクのために、以前に軽率に書かれた不完全な解決策を常に書き直すよりも、機能的で拡張可能で互換性のあるコードを書くことは、ひどいことではない。