bool checkOrderSend=OrderSend(request,result);
if(checkOrderSend) // (*** look here)
{
if(result.retcode==10009 || result.retcode==10008)
{
Print("OrderSend was successful. Code: ",result.retcode);
volume-=result.volume; //If order was successful then reduce volume to 0.0, then the loop will be terminated.break;
}
else
{
Print(ResultRetcodeDescription(result.retcode));
}
}
else
{
Print("OrderSend execution error.");
}
こんにちは、FinanceEngineerさん、多分、元のコードの複数注文の問題のチェックを始めた方がいいと思います。そうすれば、おそらく、ここで他の重要なポイントに対処して、焦点を失わないでしょうから、どうでしょうか?
こんにちは、figurelliです。
これは私の新しいコードです。このスレッドで複数注文の問題を提起して以来、変更しました。
今のところ、このコードはいくつかのブローカーで問題なく動作しています。BlindMistはこのコードを試して、そのブローカーでの複数注文の問題を避けられるかどうか確認することができます。
こんにちは、figurelliです。
これは私の新しいコードです。このスレッドで複数注文の問題を提起して以来、変更しました。
今のところ、このコードはいくつかのブローカーで問題なく動作しています。BlindMistはこのコードを試して、そのブローカーでの複数注文の問題を回避できるかどうかを確認することができます。
コードを投稿するときは、SRCボタンを使ってください。
投稿されたコードは、(すべての)二重注文を回避することはできませんし、逆に二重注文を誘発する場合もあります。
コードを投稿する際は、SRCボタンを使用してください。
投稿されたコードは(すべての)二重注文を回避することはできませんし、逆に二重注文を誘発する場合もあります。
こんにちは、figurelliです。
これは私の新しいコードです。このスレッドで複数注文の問題を提起して以来、変更しました。
今のところ、このコードはいくつかのブローカーで問題なく動作しています。BlindMistはこのコードを試して、そのブローカーでの複数注文の問題を避けられるかどうか確認することができます。
FinanceEngineer さん、あなたのオリジナルのコードでは、if { } と else { } のところに Print("OrderSend Code: "...) があることに注意してください。
しかし、else { }にはbreakがあり、あなたのデバッグコードではretcode = 10008 (TRADE_RETCODE_PLACED) x 10と表示されています。
ということは、推論するに、if { }条件のデバッグを出力していて、ブレークが使われていないのでは?
しかし、OrderSend()の戻り値をテストしておらず、result.retcodeだけをテストしていることに注意してください。変数checkOrderSend (*** look here)を使って修正することができます。
ですから、私見ですが、まず、このテストを修正し、報告された問題のあるブローカーを使用して再度チェックします。つまり、これはあなたのコードが将来にわたって安全であることを示すのではなく、バグを 発見したことを示すのです。
実際、バグが発生していないのですから、コードを再度変更することは避けられますが、この場合、OrderSend()の戻り値をもうテストしていないことに注意しなければなりません。
この情報があなたのお役に立つことを願っています。
FinanceEngineer さん、元のコードでは、if { } と else { } で Print("OrderSend Code: "...) となっていますね。
しかし、else { }にはbreakがあり、あなたのデバッグコードはretcode = 10008 (TRADE_RETCODE_PLACED) x 10を示しています。
ということは、if { }条件のデバッグで、ブレークが使われていないことが推論されます。
しかし、OrderSend()の戻り値をテストしておらず、result.retcodeだけをテストしていることに注意してください。あなたは、私が前に尋ねた変数checkOrderSend(***ここを見てください)を使用して、これを修正することができました。
ですから、私見ですが、まず、このテストを修正し、報告された問題のあるブローカーを使用して再度チェックします。つまり、これはあなたのコードが将来にわたって安全であることを示すのではなく、バグを 発見したことを示すのです。
実際、バグが発生していないのですから、コードを再度変更することは避けられますが、この場合、OrderSend()の戻り値をもうテストしていないことに注意しなければなりません。
この情報があなたのお役に立つことを願っています。
返されたコードが10010の場合はどうでしょうか?
ダブルエントリー注文はどのブローカーでも発生しますが、アルパリではより多くのティックを受け取れるため、発生する確率が高くなります。
リターンコード10010はどうですか?
ダブルエントリー注文はどのブローカーでも発生しますが、アルパリではより多くのティックを受け取ることができるため、発生する確率は単純に高くなります。
FinanceEngineer さん、元のコードでは、if { } と else { } で Print("OrderSend Code: "...) となっていますね。
しかし、else { }にはbreakがあり、あなたのデバッグコードではretcode = 10008 (TRADE_RETCODE_PLACED) x 10と表示されています。
ということは、推論するに、if { }条件のデバッグを出力していて、ブレークが使われていないのではないでしょうか。
しかし、OrderSend()の戻り値はもうテストしておらず、result.retcodeだけであることに注意してください。変数checkOrderSend(***ここを見てください)を使ってこれを修正することができます。
ですから、私見ですが、まず、このテストを修正し、報告された問題のあるブローカーを使用して再度チェックします。つまり、これはあなたのコードが将来にわたって安全であることを示すのではなく、バグを 発見したことを示すのです。
実際、バグが発生していないのですから、コードを再び変更することを忘れるか、避けることができます。しかし、この場合、OrderSend()の戻り値をもうテストしていないことに注意しなければなりません。
この情報があなたの助けになることを願っています。
こんにちは
変な話なのですが以前のコードでOrderSend(request,result)の戻り値をチェックしたところ、複数注文の問題が発生しました。 新しいコードでは、OrderSend(request,result)の戻り値をチェックしません(ただし、ターミナルの新しいビルドでのエラーを避けるために、戻り値をいくつかの変数に代入しています。
新しいコードでは、複数注文の問題は発生しません。私は、大量のティックを送信することで定評のあるAlpari UKを使用しました。 私のコードは完璧ではないかもしれませんが、このように考えています。Meta Trader 5では、返されるコードにチェックが必要なものが結構あります。
まず、OrderCheckの戻り値、次にOrderSendの戻り値、そして3番目はresult.retcodeで割り当てられた戻り値である。最初の二つはともかく、一番気になるのは、最後の一つ+実際に約定した数量ではないだろうか。
ということで、result.retcodeを直接チェックするシンプルなコードにしました。間違っていたら訂正してください。MT5の注文執行は確かにMT4より遥かに高度で、戸惑う人も多いと思います。
ロジックだけで明確なケースを構築できないのであれば、実験を使って明確なケースを構築すればいいのです。BlindMistさんや他の方々も、OrderSend関数のチェックを省略することが実際に役に立つかどうか、このコードを自分のブローカーで試してみることをお勧めします。
よろしくお願いします。
もし、私に聞いているのなら、前にも言ったように、私はこのコードが将来にわたって安全であるとは思っていませんし、これはリターンコードの欠如についての一例に過ぎませんので、もう一度読んでみてください。
このトピックに参加している皆さんにお尋ねします。コード10010についてのメッセージを見逃してしまったのですが、どこにあるのでしょうか?
このトピックに参加している皆さんにお尋ねします。コード10010についてのメッセージを見逃しましたが、どこにあるのでしょうか?
こんにちは、アラン。
私たちは、FinanceEngineer の新しいコードと、元のコードから変更された OrderSend() の戻りコードのテストについてのアドバイスについて話しているだけなので、あなたが何を知る必要があるのか私にはよくわかりません。
なお、彼の元のコードも新しいコードもコード10010のテストはしていませんので、もしあなたに関係があるのなら、なぜ彼の最初の投稿から聞かなかったのでしょうか?
とにかく、なぜFOKの充填政策 にコード10010テストが必要なのか、説明していただけませんか?
これは、私があなたと他のモデレーターの話を見るのは初めてではないので、あなたはそれが本当にFOK(Fill Or Kill)注文にこのコードテストが必要ないくつかのケースを知っていますか、あなたは私たちと共有することができましたか?
ありがとうございました。
こんにちは
変な話なのですが以前のコードでOrderSend(request,result)の戻り値をチェックしたとき、複数の注文の問題が発生しました。新しいコードでは、OrderSend(request,result)の戻り値をチェックしません(ただし、ターミナルの新しいビルドでのエラーを避けるために、戻り値をいくつかの変数に代入しています。
新しいコードでは、複数注文の問題は発生しません。私は、大量のティックを送信することで定評のあるAlpari UKを使用しました。私のコードは完璧ではないかもしれませんが、このように考えています。Meta Trader 5では、返されるコードにチェックが必要なものが結構あります。
まず、OrderCheckの戻り値、次にOrderSendの戻り値、そして3番目はresult.retcodeで割り当てられた戻り値である。最初の二つはともかく、一番気になるのは、最後の一つ+実際に約定した数量ではないだろうか。
ということで、result.retcodeを直接チェックするシンプルなコードにしました。間違っていたら訂正してください。MT5の注文執行は確かにMT4より遥かに高度で、戸惑う人も多いと思います。
ロジックだけで明確なケースを構築できないのであれば、実験を使って明確なケースを構築すればいいのです。BlindMistさんや他の方々も、OrderSend関数のチェックを省略することが実際に役に立つかどうか、このコードを自分のブローカーで試してみることをお勧めします。
よろしくお願いします。