記事"MetaTraderプログラムを簡単かつ迅速に開発するためのライブラリ(第27部): 取引リクエストの使用 - 指値注文"についてのディスカッション - ページ 2

[Artyom Trishkin]

Реter Konow:

ほぼ4メガバイトのコードで、ライブラリーのスキーマとカスタム・メソッドは提供されていない...。自分のために書いているのか？

ユーザーの目を通して見てください。彼らが参照点なしで このすべてを理解するのはどんな感じなのか。

自給自足の良い参照点は、記事そのものだ。ガイドラインがあるだけでなく、徹底的に咀嚼されている--読むのが億劫なら。

スキームはライブラリー作成の最後にある。ライブラリーの全機能に素早くアクセスするためのユーザー・ケース・メソッドと同様に。

[Artyom Trishkin]

Реter Konow:

特にこの記事には、なぜインターネット接続後すぐに、ユーザーに再質問することなく、 保留中の注文を 送信することにしたのか、その理由が書かれていない。

この記事で紹介されている保留注文は実際の取引では使えないという警告がある。つまり、これはコンセプトテストであり、それ以上のものではない。

インターネットに再接続した後、ユーザーをポーリングせずに注文を設定することについての説明はありません。

また、保留中の取引要求という単純なメカニズムをテストするのに、本当に複数の記事が必要なのでしょうか？しかも、ユーザーを再度ポーリングする方が簡単で正しい。

あなたが取引関数を書いたことがなく、私たちが話していることをよく理解していないことはすぐにわかります。

トレードサーバーのエラーには、トレードリクエストをサーバーに再送信する前に若干の遅延を必要とするものがあります。
通常、Sleep()の助けを借りてこの遅延を行うことが推奨されています。しかし、これはプログラムの実行を停止します。そのため、プログラム全体は、サーバーに取引リクエストを再送信する前に、取引メソッド内の一時停止が完了するのを待つことになります。
これは良いことでしょうか？一般的で最も単純なケースでは問題ありません。
しかし、Expert Advisorは多通貨に対応しています。そして、その待機時間中は、この待機時間以外は何もしません。
それは良いことでしょうか？エキスパート・アドバイザーは、すべての作業シンボルについて環境を監視し続けるべきです。サーバーから待機を必要とするエラーを受信すると、必要な試行回数とその間の必要な待機時間を持つ保留中のリクエストを作成し、業務を続行します。そして、取引クラス自身が時間内に必要な取引リクエストをサーバーに送信します。同時に、まず「取引リクエストに割り当てられたすべての試行の実行時間が経過していないか」をチェックします。したがって、エキスパートアドバイザーは、150時間後にサーバーに古い注文を送信することはありません。

また、プログラムとのコミュニケーションがお好きな方は、私が提案する「保留中の取引リクエスト」で、取引注文を送信する条件を設定することができます。条件を設定し、取引を開始すれば、条件が発生次第、注文が発注される。これは、Expert Advisor用の取引ロジックを作成する多くの方法の1つです。必要な値を入力し、リクエストの種類と動作するタイミングを指定するだけです。

なぜこのようなことが必要なのか」という質問に対する答えとして、まず思いつくのはこのようなことです。すべては「今ここで」ではなく、レンガを積み重ねるように、少しずつ行われていくのです。

[Реter Konow]

Artyom Trishkin:

あなたがトレーディング関数を書いたことがなく、何を言っているのかよく分かっていないことはすぐに分かる。

トレードサーバーのエラーには、トレードリクエストをサーバーに再送信する前に遅延が必要なものがあります。
通常、Sleep()の助けを借りてこの遅延を行うことが推奨されています。しかし、これはプログラムの実行を停止します。そのため、プログラム全体は、サーバーに取引リクエストを再送信する前に、取引メソッド内の一時停止が完了するのを待つことになります。
これは良いことでしょうか？一般的で最も単純なケースでは問題ありません。
しかし、Expert Advisorは多通貨に対応しています。そして、その待機時間中は、この待機時間以外は何もしません。
それは良いことでしょうか？エキスパート・アドバイザーは、すべての作業シンボルについて環境を監視し続けるべきです。サーバーから待機を必要とするエラーを受信すると、必要な試行回数とその間の必要な待機時間を持つ保留中のリクエストを作成し、業務を続行します。そして、取引クラス自身が時間内に必要な取引リクエストをサーバーに送信します。同時に、まず「取引リクエストに割り当てられたすべての試行の実行時間が終了したかどうか」をチェックします。従って、エキスパートアドバイザーは、150時間後に古い注文をサーバーに送信することはありません。

また、プログラムとのコミュニケーションがお好きな方は、私が提案する「保留中の取引リクエスト」で、取引注文を送信する条件を設定することができます。条件を設定し、取引を開始すれば、条件が発生次第、注文が発注される。これは、Expert Advisor用の取引ロジックを作成する多くの方法の1つです。必要な値を入力し、リクエストの種類と動作するタイミングを指定します。

なぜこのようなことが必要なのか」という質問に対して、まず最初に思いつくのはこのようなことです。すべては「今ここで」行われるのではなく、レンガを積み上げるように少しずつ行われるのです。

サーバーとの接続が中断されると、Expert Advisorのすべての計算が停止します。

インターネットがない-ティックがない-マルチカレンシーエキスパートアドバイザーで 計算するものは何もない。接続を待つ必要があります。接続が回復したら、失敗した注文の送信について尋ねる必要があります。

[Artyom Trishkin]

Реter Konow:
サーバーとの接続が中断されると、Expert Advisorのすべての計算が停止します。

インターネットがない-ティックがない-多通貨Expert Advisorで計算するものは何もない。接続を待つ必要があります。接続が回復したら、失敗した注文の送信について尋ねる必要があります。

ピョートル、接続の失敗だけが、繰り返す前に待つ必要のあるエラーではありません。あなたはテストのために人為的に作り出したエラーにしがみついているだけだ...。

ライブラリにはスリープ待ちは ありません。

[Реter Konow]

Artyom Trishkin:
ピーター、 繰り返す前に待つ必要があるエラーは接続障害だけではない。 あなたはテストのために人為的に作り出したエラーにしがみついているだけだ......。

ライブラリーにはスリープ待ちはない。

サーバーへの EA 呼び出しをすべて追跡することは不可能です。

• ライブラリのメソッドを通じてのみ、サーバーに送信された取引注文を追跡できます。注文が独自の関数を通じて送信された場合はどうでしょうか？

• EAがサーバーとの通信に独自のメソッドを使用している場合、接続障害/接続の場合にどのように追跡し、何ができるのでしょうか？

そこで質問です：

• サーバー通信の問題に対する解決 策として、失敗した注文を再送信する以外に何が考えられますか？
  

失敗した注文の再送信という問題に対する解決策は（明らかに）複雑さを必要とせず、単純に解決できるからです。

[Реter Konow]

Artyom Trishkin:

...

トレードサーバーのエラーには、サーバーにトレードリクエストを再送信する前に遅延が必要なものがあります 。
通常、Sleep()を使ってこの遅延を行うことが推奨されています。しかし、これではプログラムの実行が止まってしまいます。そのため、プログラム全体はサーバーに再リクエストを送信する前に、トレード・メソッド内の一時停止が完了するのを待つことになります。
...

このようなエラーの具体的なリストと説明が必要 - 解決策としてライブラリが提供するもの。

ユーザーには、自分の機能ではなくライブラリの機能を適用してもらう必要がある。

では、一般論として、これらのエラーと解決策は何ですか？

[Реter Konow]

Реter Konow:

...

明らかに）失敗した注文を再送する問題の解決策は、複雑さを必要とせず、単純に解決されるからです。

前回の記事を見ました。そこでは、サーバーが使用できないために注文を送信できないことについてだけ書かれています。解決策の形は 私が想像するよりもずっと複雑だ。しかし、解決策の本質が 複雑になることはない。

他のタイプの繰り返しリクエストに対する解決策はない。

[Artyom Trishkin]

Реter Konow:

前回の記事を見た。サーバーが使用できないために注文を送信できないことについてしか書かれていない。解決策の形は、私が想像していたよりもずっと複雑だ。しかし、解決策の本質が 複雑になることはない。

他のタイプの繰り返しリクエストに対する解決策はない。

調べてみてください :)

保留中のクエリの処理をテストするために、わざと起こりうるエラーのうちの1つだけをエミュレートしていることに気づかないとは...。次の記事では、このエミュレーションを簡略化しました - ターミナルの自動取引ボタンに対する反応があります。

エラーのリストはコードにあります。読まない人のためにもう一度説明するのはやめておこう。

[Реter Konow]

Artyom Trishkin:
そしてあなたはそれをテストする）

保留中のリクエストの処理をテストするために、起こりうるエラーの1つだけを特別にエミュレートしたのです。次の記事では、このエミュレーションを簡略化しました - ターミナルの自動取引ボタンに対する反応があります。

エラーのリストはコードの中にある。読まない人のためにもう一度説明するのはやめておこう。

これは答えではない。

あなたは、このトピックについてコミュニケーションをとり、ライブラリーがどのような保留中のリクエストに対応できるかを示したくないのでしょう。

それぞれの保留中のリクエスト（オーダーではない）には、独自の解決策、つまり独自の魔法、独自のプロパティ、独自のメソッドなどが必要だ。 それはどこにあるのか？

[Artyom Trishkin]

Реter Konow:

それは答えになっていない。

その話題についてコミュニケーションを取り、図書館がどのような保留中のリクエストに対応できるかを示したくないのでしょう。

それぞれの保留中のリクエスト（順番ではない）には、独自の解決策が必要だ。独自のマジック、独自のプロパティ、独自のメソッドなどなど。それはどこにあるのか？

このトピックについてコミュニケーションを取りたくないのは私ではなく、あなたがこのトピックの本質を理解していないからです。

この3つの記事では、保留中のリクエストを使った取引という新しい取引のコンセプトをテストしている。各記事で徐々に新しいオブジェクト-クエリが追加されている。さらに、これは一時的に作成されたクラスでの コンセプトのテストに過ぎません。このトピックの第4回では、このようなオブジェクトの本格的なクラスが作成されます。そして、その数は多くはないが、このコンセプトの必要性をすべてカバーするには十分である。

ただ、もう一度すべてを説明させないために、なぜそれが必要なのか、どんな可能性を与えてくれるのかを理解してほしい。私が挙げたのは、すぐに思い浮かんだいくつかの例だけです。