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

[MetaQuotes]

新しい記事 MetaTraderプログラムを簡単かつ迅速に開発するためのライブラリ(第27部): 取引リクエストの使用 - 指値注文 はパブリッシュされました:

この記事では、取引リクエストの開発を継続し、指値注文の発注を実装し、検出された取引クラス使用の欠点を排除します。

前の記事では、保留中取引リクエストの実装を開始し、サーバにリクエストを送信した後に取引クラスでエラーが受信された場合にポジションを開くための最初の保留中リクエストを作成しました。本稿では、保留中リクエストの開発を再開し、指値注文の設定中にエラーが発生した場合の保留中リクエストの作成を実装します。

取引クラスのテスト中に、いくつかの欠点が見つかりました。特に、クラスコンストラクタで銘柄の取引オブジェクトを初期化するときに、ハードセットのデフォルト値が設定されていました。これらの値のすべてが銘柄仕様でサポートされているわけではありません。これにより、指値注文をしようとしたときに、サーバで「サポートされていない注文有効期限タイプ」エラーが発生しました。このエラーはどこでも修正されず、最終的に指値注文をすることができなくなっていました。デフォルト値で取引リクエストを送信することによって、サポートされていないデータも取引リクエストに送信されていました。この問題を解決するには、取引リクエストで適切な銘柄仕様に対応する正しいデータを直接指定する必要がありました。

これには、銘柄仕様の知識とともに、ライブラリ自体による値の自動修正ではなくプログラムコードで正確な値を手動入力することが必要でした。物事を簡素化するために、取引クラスの処理ロジックを少し変更します。すべての銘柄取引オブジェクトは、EAのOnInit()ハンドラで正しい値を自動選択することにより初期化されます。注文と有効期限タイプに対してはデフォルトで-1の値が取引クラスの取引メソッドに渡され、事前設定された正しいデフォルト値を使用するべきことを示します。プログラムから別の値が渡された場合、その値が代わりに適用されます。無効な値は、取引クラスでエラーを処理するときに修正されます。

作者: Artyom Trishkin

[Реter Konow]

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

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

[Реter Konow]

もう一つの質問：インターネットが使えなくなった後、ユーザーと再面談することなく、保留中の注文を 設定することは、どの程度「合理的」なのだろうか？ユーザーがインターネットを再開するのに1時間かかり、状況が劇的に変化した場合、注文を自動的に設定する価値があるのだろうか？インターネットが使えないために注文が設定されなかったというメッセージを残し、再度注文を設定するかどうかはユーザーが判断する方が良いのではないでしょうか？

[Artyom Trishkin]

Реter Konow:
もう一つの質問：インターネットが使えなくなった後、ユーザーと再面談することなく、保留中の注文を 設定することは、どの程度「合理的」なのだろうか？ユーザーがインターネットを再開するのに1時間かかり、状況が劇的に変化した場合、注文を自動的に設定する価値があるのだろうか？インターネットに接続できなかったため、オーダーが設定されなかったというメッセージを残し、ユーザーが再度設定するかどうかを決める方が良いのではないか？

この記事には、その原理と理由は書かれていないのか？

[Реter Konow]

Artyom Trishkin:
この記事には、その原理と理由は書かれていないのですか？

特にこの記事には、なぜインターネット接続直後に保留中の注文を 送信することにしたのか、ユーザーを何度もポーリングする必要がないのかが書かれていません。

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

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

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

[Alexey Viktorov]

Реter Konow:

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

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

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

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

これは、何かを理解したい人のために書かれた記事であることを忘れないでください。これはプログラミングレッスンのほんの一部であり、既製のExpert Advisorではありません。この記事では、望ましい結果を得るために何をどのようにすればよいかを説明し、コードで示しています。エキスパートアドバイザーでユーザー投票を行う必要がある場合、誰もそれを禁じてはいません。

[Artyom Trishkin]

Реter Konow:

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

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

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

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

なぜそれが必要なのか、前回の記事をお読みください。ヒント

1.Sleep()関数はExpert Advisorの実行を停止します。全く。

2.マルチカレンシーのExpert Advisor。

この概念をよく理解していない。したがって、このような質問となる。

ユーザー調査のためにすべてがなります。ライブラリによって。しかし、内部取引方法ではない - 彼らはそれをすべきではないとしません。

[Реter Konow]

Alexey Viktorov:

これは、何かを理解したい人のために書かれた記事であることを忘れないでください。これはプログラミングレッスンのほんの一部であり、既製のExpert Advisorではありません。この記事では、望ましい結果を得るために何をどのようにすればよいかを説明し、コードで示しています。エキスパートアドバイザーでユーザー投票を行う必要がある場合、誰もそれを禁じてはいません。

1.1.理解したい人のために、資料のオリエンテーションを容易にするためのライブラリスキームを作るのは良いことだ。

2.2.トレーディング機能において 著者が行った各修正は、すべての記事に掲載する理由にはならない。資料が肥大化している。同じ取引機能が、マイナーチェンジされながら記事ごとに入れ替わる。今、保留中の要求のコードがあるのだろうか？これでは読者を混乱させるだけである。

3.3.もうすぐ30本の記事が出るが、著者はライブラリーを使わないよう警告している。それでは何のためのものなのか？使うのが好ましくないライブラリの書き方を教えるため？

[Artyom Trishkin]

Реter Konow:

1.理解したい人に配慮して、資料のナビゲーションが簡単になるようなライブラリ図を作るといいと思う。

2.2.トレーディング機能で 著者が行った各修正は、すべての記事に掲載する理由にはならない。資料が肥大化している。同じ取引関数が、マイナーチェンジで記事ごとに入れ替わる。今、保留中の要求のコードがあるのだろうか？これは読者を混乱させるだけである。

3.3.もうすぐ30記事になるが、著者はライブラリーの使用を控えるよう警告している。何のための記事なのか？使いたくないライブラリの書き方を教えるため？

ミンチを生で食べるのか？ここでは、それを食べないように、そして警告が与えられている - この記事と最後の記事では、資料の準備とコンセプトのデバッグがある。

そして、必要であれば、方法を変更し、その変更について説明する。

私は質問の荒らしを支持しない - 私は本質的な会話が好きだ。

[Реter Konow]

Artyom Trishkin:
ミンチを生で食べますか？ここでは、それを食べないように、警告が与えられている - この記事と最後の記事では、材料を準備し、コンセプトをデバッグしている。

そして、はい、必要に応じて、メソッドを変更し、変更点を説明します。

私は質問で荒らしを支持しない - 私は実質的な会話が好きです。

記事には完成された解答があるべきだと思っていました。そして、デバッグするために何がありますか？

サーバーとの通信が中断された場合、注文データを記録し、サーバーとの通信を再チェックするフラグを設定する。接続が確立するまでループで再確認する。通信が回復したら、失敗した注文を設定するかどうかをユーザーに尋ねる。もし「はい」なら、注文を送り返し、フラグを削除し、失敗した注文のリストから注文データを削除する。一般的に、全体のコンセプトは

[Алексей Тарабанов]

かなり実質的なようだ。