Artyom、必要な情報を1つの記事にまとめてくれてありがとう!お気に入りに追加しました。
ありがとう、ウラジーミル。
興味深い記事をありがとう。しかし、OrderCheck() 関数にほとんど注意が払われていないのは残念です。
この便利な関数に特化した別の記事を期待しているのだが...。
興味深い記事をありがとう。しかし、OrderCheck() 関数にほとんど注意が払われていないのは残念です。
この便利な関数に特化した別の記事を期待しているのだが...。
私はちょうど「拡張ヘルプ」を書いていたところでした。そして、OrderCheckに関するすべてが簡潔ですっきりしている。そして、それ自体に過不足はない。私は、フィールドに何が、何が、どのように記入されているかを説明した。すべての場合に記入されるわけではありません。取引依頼を正しく記入することに慣れているため、コード付き関数の応答はほとんどいつも「OK」である。ほとんど "というのは、仕事をチェックするためにわざと間違ったデータを入力しているのです。つまり、そこに何を記述すればいいのか、記事にしてもさっぱりわからないのである。
私はちょうど "拡張ヘルプ "を書いていた。しかし、OrderCheckに関することはすべて簡潔ですっきりしているようだ。そしてそれ自体に過不足はない。私は、フィールドに何が、何が、どのように記入されているかを説明した。すべてのケースで記入されるわけではありません。取引依頼を正しく記入することに慣れているため、コード付き関数の応答はほとんどいつも「OK」である。ほとんど "というのは、仕事をチェックするためにわざと間違ったデータを入力しているのです。つまり、そこに何を記述すればいいのか、記事にしてもさっぱりわからないのである。
少なくとも、MqlTradeCheckResultの構造を注意深く読んだことのある人はほとんどいない。
struct MqlTradeCheckResult { uint retcode; // レスポンスコード double balance; // 取引後の残高 double equity; // 取引後の資本 double profit; // 浮動利益 double margin; // 必要証拠金 double margin_free; // フリー・マージン double margin_level; // マージンレベル string comment; // レスポンス・コードへのコメント(エラーの説明) };
そしてたいていの場合、彼らはこの関数はドキュメントに書かれているように専ら 意図されたものだと言う。
OrderCheck()関数は、必要な 取引 操作に必要な資金の十分性をチェックする。
しかし、"Balance after ..." と "Equity after ..." という構造のフィールドに注意を払う価値がある。必要証拠金」のことではありません。これらのパラメータは非常に便利です。例えば、取引を行った後、口座に「40コペイカ」のエクイティが残っていた場合、十分な資金があり、注文の他のパラメータが正常であったとしても、そのような取引を行う必要があるのでしょうか?もちろん、別の方法でこの値を取得することも可能だが、私の考えでは、1つの関数でいくつかの有用なパラメータを取得する方がはるかに有利である。
また、私の使用経験によれば、チェックに成功した場合、レスポンス・コードは間違ったSLやTPの価格を修正する。それだけではありません。この点について記事を書いてもらいたい。他のコードについて
残念ながら、OrderCheck() はエラーを報告しない。
10018 | トレード_リートコード_マーケット_クローズド | マーケットがクローズされた。 |
というわけで、開発者はようやくこの問題に注意を払うようになるかもしれない...。
少なくとも、MqlTradeCheckResultの構造を注意深く読む人は少ない。
そして、ほとんどの場合、この関数はドキュメントに書かれているように排他的な ものだと言います。
しかし、"Balance after ..." と "Equity after ..." という構造のフィールドには注意を払う価値があります。必要証拠金」の話では全くありません。これらのパラメータは非常に便利です。例えば、取引を行った後、口座に「40コペイカ」のエクイティが残っていた場合、十分な資金があり、注文の他のパラメータが正常であったとしても、そのような取引を行う必要があるのでしょうか?もちろん、別の方法でこの値を取得することは可能ですが、私の考えでは、1つの関数でいくつかの有用なパラメータを取得する方がはるかに有利です。
また、私の使用経験によれば、チェックに成功した場合、レスポンス・コードは間違ったSLやTPの価格を修正する。それだけではありません。この点について記事を書いてもらいたい。他のコードについて
残念ながらOrderCheck()はエラーを報告しない 。
10018 | トレード_リートコード_マーケットクローズ | マーケットクローズ |
というわけで、開発者たちはようやくこの問題に注意を払うようになるかもしれない・・・。
SLとTPって何のこと?それらは構造の分野にはない...
そして、エクイティ、取引後の残高について...ええと...、その...、それを知ることは有益で、このデータはサーバーに注文を送る前に分析されるべきだ、と言おうと思ってたんだ。でも、言わなかったかな?それとも、後で饅頭を買うだけの資金がないのなら、ポジションを開くべきではない、と明言しておくべきだったか?でもね、思ったんだ。だから、この構造のフィールドを分析すれば いい、と書いたんだ。そして、「市場が閉じた」が返されないことについては、(書きたかったのだが)単に忘れてしまったので書かなかった。)そして、これらはトレード・サーバーのリターン・コードだと思った。これらは、生活のすべてのケースのためのものです。どうやら、このコードはこのケース用ではないようだ。OrderSendでは普通に戻る。マーケットがクローズしているかどうかをチェックするには、オーダーを送信する必要がある。しかし、そこには何がある。
コードについて話している
10014 | トレード_レトコード_インバリッド_ボリューム | リクエストのボリュームが正しくない |
10015 | 取引コード_無効な価格 | リクエストの価格が不正です |
10016 | 取引コード_無効なストップ | リクエストのストップが正しくない |
これらのコードはMqlTradeCheckResult構造体に返され、完全に分析される。
つまり、もしあなたが書きたくないなら、あるいはラシードが歓迎しないなら、私は主張しない。
さて、ここで「レスポンスコードを分析できます」以外に何が書けるだろうか?まあ、そんなコードを受け取った人がいる。だから、間違ったストップがないようにプログラムで処理しなければならない。応答コードの分析も分析です。構造フィールドと同様に。つまり、すべては分析し、結論を出すということだ。それとも、各サーバーのレスポンスと、この場合どのようなアクションを行うべきかを記述する必要があるとお考えですか?まあ、これはまだ書き終えていないライブラリに実装されているのですが、取引は長い間そこで行われてきました。完全な分析と調整をしながらね。なぜ繰り返すのか?
まあ、ここでは「レスポンスコードを分析すればいい」以外に何を書けばいいのか......。このようなコードを受け取った人は、ストップが正しくないことは明らかです。だから、間違ったストップがないようにプログラムで処理しなければならない。応答コードの分析も分析である。構造フィールドと同様に。つまり、すべては分析し、結論を出すということです。それとも、各サーバーのレスポンスと、この場合どのようなアクションを行うべきかを記述する必要があるとお考えですか?まあ、これはまだ書き終えていないライブラリに実装されているのですが、取引は長い間そこで行われてきました。完全な分析と調整をしながらね。なぜ繰り返すのか?
リターンコードを取得して分析するためには、少なくともこの関数が何であるかを理解し、その有用性を理解する必要がある。これはまさに私が言っていることだ。この記事では、ドキュメントからの説明だけでなく、関数の拡張された理解を提供します。
取引トランザクション。リクエストとレスポンスの構造、説明、ログ出力」についての議論。
アレクセイ・ヴィクトロフ, 2023.08.03 13:40
少なくとも、MqlTradeCheckResultの構造を注意深く読む人はほとんどいません。
struct MqlTradeCheckResult { uint retcode; // レスポンスコード double balance; // 取引後の残高 double equity; // 取引後の資本 double profit; // 浮動利益 double margin; // 必要証拠金 double margin_free; // フリー・マージン double margin_level; // マージンレベル string comment; // レスポンス・コードへのコメント(エラーの説明) };
そして、ほとんどの場合、彼らはこの関数がドキュメントに書かれているように排他的に 意図されていると言います。
OrderCheck()関数は、必要な取引操作に必要な資金が十分にあるかどうかをチェックします。
トレーディング取引。リクエストとレスポンスの構造、説明、ログ出力" の議論
アレクセイ・ヴィクトロフ, 2023.08.03 19:55
あなたが書きたくないなら、あるいはラシードが歓迎しないなら、私は主張しません。

- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事「取引トランザクション:リクエストとレスポンスの構造体、説明、ロギング」はパブリッシュされました:
この記事では、取引リクエストの構造体、すなわち、リクエストの作成、サーバーに送信する前の事前検証、取引リクエストに対するサーバーの応答、および取引トランザクションの構造体の取り扱いについて検討します。取引注文をサーバーに送信するためのシンプルで便利な関数を作成し、すべての議論された内容に基づいて、取引トランザクションを通知するEAを作成します。
MQL5には、未決注文を出し、ポジションを開き、注文やポジションを変更するためのOrderSend()関数があります。この関数の最初の入力は、MqlTradeRequest取引リクエストの構造体です。構造体のactionフィールドは、実行されるアクションのタイプを示し、残りのフィールドは、actionフィールドで選択されたアクションに応じて入力されます。こうして、取引リクエストに必要なパラメータを関数に渡すことで、サーバーにさまざまなリクエストを送ります。
作者: Artyom Trishkin