Have doubt regarding FoK order type. In my view if order is not filled a reject message should be sent by an exchange instead of cancel. Can someone confirm this? No, rejections are to convey that the requested action was not carried out. A FoK order not being filled does not fall in this category, it is rather "works as designed". It is...
こんにちは
変な話なのですが以前のコードでOrderSend(request,result)の戻り値をチェックしたとき、複数の注文の問題が発生 しました。 今、私の新しいコードでは、OrderSend(request,result)の戻り値をチェックしません（しかし、ターミナルの新しいビルドでのエラーを避けるために、戻り値をある変数に割り当てました）。
私の意見では、あなたは以前のコード（10008の戻り値）でこの（#）を印刷しているので、本当の問題を隠しているだけで、ブレークの状況ではないと思います。
こんにちは、アラン。
FinanceEngineerの 新しいコードと、元のコードから変更されたOrderSend()の戻りコードのテストについてのアドバイスについて話しているだけなので、あなたが何を知る必要があるのか私にはわかりません。
なお、彼の元のコードも新しいコードもコード10010のテストはしていませんので、もしあなたに関係があるのなら、なぜ彼の最初の投稿から聞かなかったのでしょうか？
とにかく、なぜFOKの充填政策 にコード10010テストが必要なのか、説明していただけませんか？
これは、あなたや他のモデレーターが話しているのを見るのは初めてではないので、FOK (Fill Or Kill) 注文のためにこのコードテストが本当に必要なケースをご存知ですか、私たちと共有できますか？
ありがとうございました。
私はこのフォーラムで質問をすることができると仮定し、常に答えなければならないだけでなく。単にそれだけです。
10008や10009に対して返されたコード（MqlResult）をテストするコードをここでたくさん見ますが、これらのコードの本当の意味は何なのか、「注文が行われた」と「リクエストが完了した」の違いは何なのか、誰か説明してくれませんか？エラーコードでないのは、この2つのコードだけですよね？
10010は疑問である、文書は言った。
10008
トレード_リコード_配置
注文が置かれた
10009
トレード_レトコード_完了
リクエスト完了
10010
トレード_リトレード_ドーン_パーシャル
リクエストの一部のみが完了した
しかし、「リクエストの一部しか完了しませんでした」とはどういう意味でしょうか。FOK のフィリングポリシーでは、1 ロットを要求したら 0.5 ロットを開けるということはありえない（例）、と書かれていますが、これだけの意味なのでしょうか？
以前、10010コードについて書かれていました。
私はこのコードが将来にわたって安全であるとは考えていませんし、これはリターンコードの欠如に関する一例に過ぎませんので、もう一度お読みください。
この文章はどういう意味なのでしょうか？"将来性"？「十分な安全性......？「リターンコードの欠如」、何が欠如しているのでしょうか？(そして、あまり重要ではありませんが、"read again "とは何でしょうか？）
このフォーラムで質問して、いつも答えなければならないわけではないと思っています。単にそれ。
我々は、10008または10009に対して返されたコード（MqlResult）をテストし、ここで多くのコードを参照してください、しかし、誰かがこれらのコードの本当の意味を説明することができます、何が "Order Placed" と "Request completed" の間に違いがあるのでしょうか？エラーコードでないのは、この2つのコードだけですよね？
10010は疑問です、ドキュメントによると。
10008
トレードコードプレイスド
注文が入りました
10009
トレード_レトコード_完了
リクエスト完了
10010
トレード_リトレード_ドーン_パーシャル
リクエストの一部のみが完了した
しかし、「リクエストの一部しか完了しませんでした」とはどういう意味でしょうか。FOK のフィリングポリシーでは、1 ロットを要求したら 0.5 ロットを開けるということはありえない（例）、と書かれていますが、これだけの意味なのでしょうか？
以前、10010のコードについて書かれていました。
この文の意味は何でしょうか？"Future proof" ?「十分な安全性"・・・？"Lack of return code", 何が足りないのでしょうか？(そして、あまり重要ではありませんが、"もう一度読む "とは何でしょうか？）
他の人と同じように、私もMQL5のコーディングは他の人のコードを見て学びました。不思議なことに、今のところ、10010のコードをチェックするコードは見当たりません。しかし、チェックする価値はあるかもしれません。念のため。
私が見た限りでは、10008のコードを単独でチェックすると、ダブルエントリーオーダーが発生しました。また、10009のコードも一緒にチェックすると、ダブルエントリーオーダーが発生しました。10008と10009の両方をチェックすると、ダブルエントリーオーダーは出ませんでした。
このような場合、どのように対処するのが効率的なのでしょうか？
おそらく、この注文送信問題のほとんどは、ループ内でPositionGetDouble(POSITION_VOLUME)を使用してボリュームをチェックすることで対処できるのではないかと思います。しかし、これが10008や10009のコードをチェックするよりも効率的であるかどうかは、現実的にはわかりません。
ブローカーのサーバーがビジー状態であれば、正しいボリュームを取得できない可能性は、10008または10009コードを取得できない可能性と等しくなります。
よろしくお願いします。
こんにちは、アラン。
FinanceEngineerの 新しいコードと、元のコードから変更されたOrderSend()の戻りコードのテストについてのアドバイスについて話しているだけなので、あなたが何を知る必要があるのか私にはわかりません。
なお、彼の元のコードも新しいコードもコード10010のテストはしていませんので、もしあなたに関係があるのなら、なぜ彼の最初の投稿から聞かなかったのでしょうか？
とにかく、なぜFOKの充填政策 にコード10010テストが必要なのか、説明していただけませんか？
これは、私があなたと他のモデレーターが話しているのを見るのは初めてではないので、あなたはそれが本当にFOK（Fill Or Kill）注文のためのこのコードテストが必要ないくつかのケースを知っていますか、あなたは私たちと共有することができましたか？
ありがとうございました。
MQL5.comフォーラムに投稿するとき、私たちはエキスパートアドバイザーをコーディングする際にいくつかのタイプのニーズを持っている人々と話していると仮定します... この場合、すべてを単純化して、ユーザーのニーズがあなたが想像するほど「高度」でない場合は「より単純な」エキスパートアドバイザーをコーディングするように依頼できることは明らかです。しかし、私が知る限り、FOK充填ポリシーで作業できない 状況がいくつかあります。
私はあなたに非常に簡単な例を与えてみましょう：あなたが株式で作業していると選択したボリュームは10,000株であるとします。今、この同じエキスパートアドバイザーは、 "反転 "で動作するので、いくつかのランダムな信号で、いわゆる "反転 "を実行するために20,000株に等しいボリュームで市場に注文を送信する必要があるかもしれないと仮定します。この場合、非常に流動性の高い銘柄（例えば、ブラジルのヘビー級銘柄PETR4やVALE5）であっても、ある瞬間に20,000株に相当する買付量や売付量がないことがあります。この場合、エキスパートアドバイザーの内部でどのようにこれを扱うのでしょうか？あなたは本当にFOKのポリシーは、この場合の最善のアプローチであると確信していますか？それとも、エキスパートアドバイザーの内部でこの10010コードを考慮しようとするでしょうか？
言われたように、あなたが常に小ロットで作業する場合、FOK充填方針はあなたの最良の解決策になる可能性があります。しかし、時々、人々はより "高度な "ニーズを持っています...
このフォーラムで質問して、いつも答えなければならないわけではないと思っています。単にそのことです。
10008や10009に対して返されたコード(MqlResult)をテストする多くのコードをここで見ますが、これらのコードの本当の意味は何なのか、「注文が行われた」と「リクエストが完了した」の違いは何なのか、誰か説明してくれませんか？エラーコードでないのは、この2つのコードだけですよね？
10010は疑わしい、ドキュメントは言った。
10008
置かれる貿易_retcode
注文が置かれた
10009
トレード_レトコード_完了
リクエスト完了
10010
トレード_リトレード_ドーン_パーシャル
リクエストの一部のみが完了した
しかし、「リクエストの一部しか完了しませんでした」とはどういう意味でしょうか。FOK のフィリングポリシーでは、1 ロットを要求したら 0.5 ロットを開けるということはありえない（例）、と書かれていますが、これだけの意味なのでしょうか？
以前、10010のコードについて書きましたね。
この文章はどういう意味なのでしょうか？"将来性"？「十分な安全性......？「リターンコードの欠如」、何が欠如しているのでしょうか？(そして、あまり重要ではありませんが、"read again "とは何でしょうか？）
アラン、問題ありません。これは良いOMSプロトコルでは必須なので、おそらくあなたはケースを見つけることができないので、答える必要はありません。
また、これはおそらくオフトピックであるため、あなたは最初の投稿の後に尋ねなかった理由を話す必要はありません。
とにかく、FOKは古い充填ポリシーで、MQはおそらくOMSとの通信に対処するために導入されたので、例えばFIXのようなすべての良いOMSプロトコルでそれを見つけることができます（2009年、MT5が存在する前のこのフォーラムのトピックのように）ことに注意してください。
ですから、私の意見では、FillまたはKill注文の10010リターンコードについて質問する理由はないと思います。このルールは必須であり、ブローカーとOMSプロバイダーはこれを尊重しなければならないので、ここがポイントです。
MQL5.comフォーラムに投稿するとき、私たちはエキスパートアドバイザーをコーディングする際にいくつかのタイプのニーズを持っている人たちと話していると思います。この場合、すべてを単純化して、ユーザーのニーズが想像するほど「高度」でない場合は「よりシンプルな」エキスパートアドバイザーをコーディングするようユーザーに依頼できることは明らかです。しかし、私が知る限り、FOK充填ポリシーで作業できない 状況がいくつかあります。
私はあなたに非常に簡単な例を与えてみましょう：あなたが株式で作業していると選択したボリュームは10,000株であるとします。今、この同じエキスパートアドバイザーは、 "反転 "で動作するので、いくつかのランダムな信号で、いわゆる "反転 "を実行するために20,000株に等しいボリュームで市場に注文を送信する必要があるかもしれないと仮定します。この場合、非常に流動性の高い銘柄（例えば、ブラジルのヘビー級銘柄PETR4やVALE5）であっても、ある瞬間に20,000株に相当する買付量や売付量がないことがあります。この場合、エキスパートアドバイザーの内部でどのようにこれを扱うのでしょうか？あなたは本当にFOKのポリシーは、この場合の最善のアプローチであると確信していますか？それとも、エキスパートアドバイザーの内部でこの10010コードを考慮しようとするでしょうか？
言われたように、あなたが常に小ロットで作業する場合、FOK充填方針はあなたの最良の解決策になる可能性があります。しかし、時々、人々はより "高度な "ニーズを持っています...
この説明はキャッチーですね。私たちの多くは、1回の取引で100万米ドル以下の取引をすることが多いので、同じことを考えました。FXのような流動性の高い市場では、注文の一部が満たされることは稀なことかもしれない。しかし、絶対にないとは言い切れない。我々は確率的な世界に生きている。確かなことは何もない。もし、あるブローカーが1ロットを0.5ロットに分割するようなことがあれば、私は別のブローカーを探して取引することになるでしょう。
ありがとうございました。
MQL5.comフォーラムに投稿するとき、私たちはエキスパートアドバイザーをコーディングする際にいくつかのタイプのニーズを持っている人たちと話していると思います。この場合、すべてを単純化して、ユーザーのニーズが想像するほど「高度」でない場合は「よりシンプルな」エキスパートアドバイザーをコーディングするようユーザーに依頼できることは明らかです。しかし、私の知る限り、FOK充填ポリシーで作業できない 状況がいくつかあります。
私はあなたに非常に簡単な例を与えてみましょう：あなたが株式で作業していると選択したボリュームは10,000株であるとします。今、この同じエキスパートアドバイザーは、 "反転 "で動作するので、いくつかのランダムな信号で、いわゆる "反転 "を実行するために20,000株に等しいボリュームで市場に注文を送信する必要があるかもしれないと仮定します。この場合、非常に流動性の高い銘柄（例えば、ブラジルのヘビー級銘柄PETR4やVALE5）であっても、ある瞬間に20,000株に相当する買付量や売付量がないことがあります。この場合、エキスパートアドバイザーの内部でどのようにこれを扱うのでしょうか？あなたは本当にFOKのポリシーは、この場合の最善のアプローチであると確信していますか？それとも、エキスパートアドバイザーの内部でこの10010コードを考慮しようとするでしょうか？
言われたように、あなたが常に小ロットで作業するとき、FOK充填方針はあなたの最良の解決策かもしれません。しかし、時々、人々はより "高度な "ニーズを持っています...
こんにちは、Malacarne。
モデレーターとして、現実（ユーザーが本当に投稿したもの）とwhat if条件を混同することはできませんので、申し訳ありませんが、これはオフトピックです。
言い換えれば、ユーザーが何かを尋ねると、コードを公開し、コードは以下の行を持っている場合（最初と古いものとして）、モデレータとして我々の考え方は、彼がFOKを使用していると考える必要があります。
request.type_filling=ORDER_FILLING_FOK;そう思いませんか？もしそうでなければ、コードエラーの発見と問題分析の概念を見直す必要があると思います。
実際には、あなたのBM＆FBovespaブラジルの例として、FOKを使用しない場合は、私の考え方が変わると10010戻りコードを考慮する必要がありますが、これは絶対にオフトピックで、多分ポルトガル語フォーラムに良い議論である。
とにかく、それを共有していただきありがとうございます。
説明がキャッチーです。私たちの多くは、1回の取引で100万ドル以下しか取引しないので、同じことを考えた。FXのような流動性の高い市場では、注文の一部が満たされることは稀なことかもしれない。しかし、絶対にないとは言い切れない。我々は確率的な世界に生きている。確かなことは何もない。もし、あるブローカーが1ロットを0.5ロットに分割するようなことがあれば、私は別のブローカーを探して取引することになるでしょう。
ありがとうございました。
私も他の人と同じように、MQL5のコーディングは他の人のコードを見て学びました。不思議なことに、今のところ10010のコードをチェックするコードは見当たりません。しかし、チェックする価値はあるかもしれません。念のため。
こんにちは、Malacarne,
申し訳ありませんが、モデレーターとして現実（ユーザーが本当に投稿したもの）とwhat if条件を混同することはできませんので、これはオフトピックです。
言い換えれば、もしユーザーが何かを尋ね、コードを公開し、そのコードに以下の行（最初で古いもの）があれば、モデレーターとしての私たちの考え方は、彼がFOKを使用していると考えなければなりません。
そう思いませんか？もしそうでないなら、私は、コードの誤りを見つけることや問題分析の概念を見直す必要があると思います。
実際には、あなたのBM＆FBovespaブラジルのケースのように、FOKを使用しない場合は、私の考え方が変化し、10010戻りコードを考慮する必要がありますが、これは絶対にオフトピックで、多分ポルトガル語のフォーラムに良い議論である。
とにかく、それを共有していただきありがとうございます。
ご意見ありがとうございます...私は、人々の心に「混乱」をもたらすことを意図しているわけではありません。
しかし、私はそれがオフトピックだとは思わない、あなたが10010コードをチェック しない場合、エキスパートアドバイザーは、この可能性を回避し、複数の注文を送信することができます （完全にトピックに関連していると思いませんか）...
これは、この同じトピックに関する最後の2つの投稿以来、私たちが警告 するために "しようとしている "ものです...