バーの端の注文を閉めるのを手伝ってくれ! - ページ 2 1234 新しいコメント Proximus 2013.10.26 20:51 #11 うーん、これで良いのでしょうか？ /////////////////OrderSelect() and other stuff if( OrderType() == OP_BUY ){ if( /* blablabla condition && */ Time[0]>OrderOpenTime() ){ OrderClose( OrderTicket(), OrderLots(),OrderClosePrice() ,TAKEPROFITPIPS,CLR_NONE); RefreshRates(); }} 実は、Time[1]がもう1本スキップしていたので、Time[0]に変更したのですが、Time[0]は実際にはOpen[0]を表しています。 Tjipke de Vries 2013.10.26 20:59 #12 Proximus:うーん、これで良いのでしょうか？実はTime[1]がもう1本スキップしていたので、Time[0]に変更したのですが、実際にはTime[0]はOpen[0]を表しています。誰かこれより良い、あるいはよりスムーズな方法を知っていたら教えてください RefreshRates(); OrderClose( OrderTicket(), OrderLots(),OrderClosePrice() ,Slippage,CLR_NONE); そして、ordercloseが成功するかどうかもチェック します。 Proximus 2013.10.26 21:49 #13 deVries:で、ordercloseが成功するかどうかもチェックします。 もし成功しなければ、start()関数が 繰り返されるとき、orderclose()の前にあるif()を再度テストし、条件がまだ真であるため、それを再び閉じようとするでしょう。start()の同じループで2回閉じようとすることはできません、別のティックを待つ必要がありませんか？ Simon Gniadkowski 2013.10.27 07:17 #14 Proximus: さて、成功しなかった場合、start()関数がそれ自体を繰り返すとき、それはorderclose()の前にそのif()を再度テストし、条件はまだ続行するには真であるので、それはそれを閉じようとするany.I cantはstart()の同じループで2回それを閉じようとする、別のティックを待つ必要がありますいいえ？ あなたはそれが失敗したことを知りたくないですか？ そして、それが失敗した場合、なぜ失敗したのですか？ そして、それを失敗させることができた関連する変数の値は、その時点で何でしたか？ もしあなたがこれらすべてを知っていれば、次回は失敗しないようにそれを修正することができます... ... Simon Gniadkowski 2013.10.27 07:26 #15 Proximus: うーん、これで良いのでしょうか？ 実は、Time[1]がもう1本スキップしていたので、Time[0]に変更したのですが、Time[0]は実際にはOpen[0]を表しています。 いいえ、これはティックが次のバーのティックであるかどうかに関係なく、取引が開始されたバーの次のバーとそのバー中の任意の時間について、常に閉じることになります Time[0] は常に OrderOpenTime() より大きくなります。 もし、バーの終値に近い時刻に決済したい場合は、現在のティックが新しいバーの最初のティックであるかどうかを判断する必要があります。 Tjipke de Vries 2013.10.27 07:32 #16 Proximus: まあ、成功しなかった場合、start()関数が繰り返されるとき、それはorderclose()の前にif()を再度テストし、条件がまだ進行するために真であるので、それは再びそれを閉じようとするでしょう。私はstart()の同じループで2回それを閉じてみることができない、別のティックを待つ必要がありますいいえ？ あなたはそれがバーの最後のティックを閉じなければならないことを開始しました。 最後のティックバーがいつ来るかを知ることは不可能であることを理解しようとしました。 これでクロージングが失敗しても問題なく、次のティックでもう一度、もう一度、もう一度試せるようになりました。 私が提案した他の変更も見逃しましたか？ オーダークローズ後にリフレッシュすることにどんな意味があるのでしょうか？ そして、なぜTAKEPROFITPIPSの 代わりにスリッページなのか知っていますか？ エラーリターンにもよりますが、同じループで2回クローズすることができます。 もしtradecontextが忙しすぎて、ループ内にもっと取引がある場合は、Nを閉じるために、彼らはまた失敗する可能性が大きい。 Proximus 2013.10.27 22:42 #17 RaptorUK: いいえ、これはティックが次のバーのティックであるかどうかに関係なく、取引が開始されたバーの次のバーで、そのバー中の任意の時間Time[0]は常にOrderOpenTime()よりも大きくなります。 もし、バーの終値に近い時刻に決済したい場合は、現在のティックが新しいバーの最初のティックであるかどうかを判断する必要があります。 start()は1tickごとに繰り返されるのでは？私が間違っているのでしょうか？ とにかく、このように想像してみてください。 OrderOpenTime() = 12:12:01 (12 H 12 MIN 1 SEC) 注文が開かれ、Orderclose()関数パケットはメインコードのOrderSend()関数の後にあります。 Time[0]は、このバーのオープン価格なので、共通のロジックでは、注文が開かれた時間よりも小さくなければならない、注文は同じバーopen.Itの前に開くことができないので：12時12分00秒です。 だから、すべての手段によって。 if(Time[0]>OrderOpenTime()) ordercloseはtrueの値を返すので、triggered.Ifは、スリッページなどの何らかの理由で、それを閉じることができない、問題はない、start()は自分自身を繰り返します。 そして、次の繰り返しでは、Time[0]は100％注文のオープン時間より大きくなります。これは論理的なことで、最初のクローズに失敗すると、その後、start()が繰り返されるたびに他のOrderClose()が発生します。そして、私はstart()が1目盛り ごとに繰り返すと考えているので、より速く注文を閉じる良い方法はないと思います。私はそれを明確に説明したと思います:) Proximus 2013.10.27 22:45 #18 deVries: バーの最後のティックをクローズする必要があることを開始しました。 最後のティックバーがいつ来るかを知ることは不可能であることを理解しようとしました。 これでクロージングが失敗しても問題なく、次のティックでもう一度、もう一度、もう一度試せるようになりました。 私が提案した他の変更も見逃しましたか？ オーダークローズ後にリフレッシュすることにどんな意味があるのでしょうか？ そして、なぜTAKEPROFITPIPSの 代わりにスリッページなのか知っていますか？ エラーリターンにもよりますが、同じループで2回クローズすることができます。 もしtradecontextがあまりにも忙しく、ループ内でより多くの取引をクローズする場合は、N個の大きな可能性は、彼らも失敗します。 TAKEPROFITPIPSを使うのは、TAKEPROFITの変数であり、最大スリッページをTPレベルと同じだけ許容するからで、OrderClose()で注文を閉じる場合、TP以上のスリッページがあってはならないという論理からです。 Simon Gniadkowski 2013.10.28 07:13 #19 Proximus:start()は1tickごとに繰り返されるのでは？私は間違っていますか？はい、start()はまだ実行中でない限り、各ティックで呼び出されます。Proximusとにかく、次のように想像してみてください。OrderOpenTime() = 12:12:01 (12 H 12 MIN 1 SEC)注文が開かれ、Orderclose()関数のパケットはメインコードのOrderSend()の後にあるので、注文を開いた直後にOrderClose()パケットで注文を閉じるための条件が満たされたかどうかをテストすることになります。Time[0]は、このバーのオープン価格なので、一般的なロジックでは、注文が開かれた時間よりも小さくなければならない、注文は同じバーopen.Itの前に開くことができないので：12時12分00秒です。だから、すべての手段によって。真値を返すので、ordercloseがトリガーされます。スリッページなど何らかの理由で閉じることができない場合は、問題なく、start()が繰り返されます。そして、次の繰り返しでは、Time[0]は100％注文のオープン時間より大きくなります。これは論理的なことで、最初のクローズに失敗すると、その後、start()が繰り返されるたびに他のOrderClose()が発生します。そして、私はstart()がすべてのティックで繰り返されると思っているので、より速く注文を閉じるための良い方法はないと思います。私はそれが明確に説明したと思います :) しかし、それはこのスレッドの最初の投稿であなたが求めたものではありません ... ... あなたは今、CloseがPeriodや別のPeriodで遅れるのは問題ないと言っているのです。もし、Closeをバー終了間際にしたいのであれば、次のバーの最初のティックで行う必要があり、Closeが失敗したかどうかを確認 し、正しい方法で再試行してCloseを成功させなければならないのです。 Ian Venner 2013.10.28 14:20 #20 あるバーの終値が 次のバーで繰り返されないことは非常に稀であり、必ずしもその始値が繰り返されるとは限らない ... 1234 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
うーん、これで良いのでしょうか？
実は、Time[1]がもう1本スキップしていたので、Time[0]に変更したのですが、Time[0]は実際にはOpen[0]を表しています。
うーん、これで良いのでしょうか？
実はTime[1]がもう1本スキップしていたので、Time[0]に変更したのですが、実際にはTime[0]はOpen[0]を表しています。誰かこれより良い、あるいはよりスムーズな方法を知っていたら教えてください
RefreshRates(); OrderClose( OrderTicket(), OrderLots(),OrderClosePrice() ,Slippage,CLR_NONE);そして、ordercloseが成功するかどうかもチェック します。
で、ordercloseが成功するかどうかもチェックします。
さて、成功しなかった場合、start()関数がそれ自体を繰り返すとき、それはorderclose()の前にそのif()を再度テストし、条件はまだ続行するには真であるので、それはそれを閉じようとするany.I cantはstart()の同じループで2回それを閉じようとする、別のティックを待つ必要がありますいいえ？
うーん、これで良いのでしょうか？
実は、Time[1]がもう1本スキップしていたので、Time[0]に変更したのですが、Time[0]は実際にはOpen[0]を表しています。
もし、バーの終値に近い時刻に決済したい場合は、現在のティックが新しいバーの最初のティックであるかどうかを判断する必要があります。
まあ、成功しなかった場合、start()関数が繰り返されるとき、それはorderclose()の前にif()を再度テストし、条件がまだ進行するために真であるので、それは再びそれを閉じようとするでしょう。私はstart()の同じループで2回それを閉じてみることができない、別のティックを待つ必要がありますいいえ？
あなたはそれがバーの最後のティックを閉じなければならないことを開始しました。
最後のティックバーがいつ来るかを知ることは不可能であることを理解しようとしました。
これでクロージングが失敗しても問題なく、次のティックでもう一度、もう一度、もう一度試せるようになりました。
私が提案した他の変更も見逃しましたか？
オーダークローズ後にリフレッシュすることにどんな意味があるのでしょうか？
そして、なぜTAKEPROFITPIPSの 代わりにスリッページなのか知っていますか？
エラーリターンにもよりますが、同じループで2回クローズすることができます。
もしtradecontextが忙しすぎて、ループ内にもっと取引がある場合は、Nを閉じるために、彼らはまた失敗する可能性が大きい。
いいえ、これはティックが次のバーのティックであるかどうかに関係なく、取引が開始されたバーの次のバーで、そのバー中の任意の時間Time[0]は常にOrderOpenTime()よりも大きくなります。
もし、バーの終値に近い時刻に決済したい場合は、現在のティックが新しいバーの最初のティックであるかどうかを判断する必要があります。
start()は1tickごとに繰り返されるのでは？私が間違っているのでしょうか？
とにかく、このように想像してみてください。
OrderOpenTime() = 12:12:01 (12 H 12 MIN 1 SEC)
注文が開かれ、Orderclose()関数パケットはメインコードのOrderSend()関数の後にあります。
Time[0]は、このバーのオープン価格なので、共通のロジックでは、注文が開かれた時間よりも小さくなければならない、注文は同じバーopen.Itの前に開くことができないので：12時12分00秒です。
だから、すべての手段によって。
ordercloseはtrueの値を返すので、triggered.Ifは、スリッページなどの何らかの理由で、それを閉じることができない、問題はない、start()は自分自身を繰り返します。
そして、次の繰り返しでは、Time[0]は100％注文のオープン時間より大きくなります。これは論理的なことで、最初のクローズに失敗すると、その後、start()が繰り返されるたびに他のOrderClose()が発生します。そして、私はstart()が1目盛り ごとに繰り返すと考えているので、より速く注文を閉じる良い方法はないと思います。私はそれを明確に説明したと思います:)
バーの最後のティックをクローズする必要があることを開始しました。
最後のティックバーがいつ来るかを知ることは不可能であることを理解しようとしました。
これでクロージングが失敗しても問題なく、次のティックでもう一度、もう一度、もう一度試せるようになりました。
私が提案した他の変更も見逃しましたか？
オーダークローズ後にリフレッシュすることにどんな意味があるのでしょうか？
そして、なぜTAKEPROFITPIPSの 代わりにスリッページなのか知っていますか？
エラーリターンにもよりますが、同じループで2回クローズすることができます。
もしtradecontextがあまりにも忙しく、ループ内でより多くの取引をクローズする場合は、N個の大きな可能性は、彼らも失敗します。
start()は1tickごとに繰り返されるのでは？私は間違っていますか？
はい、start()はまだ実行中でない限り、各ティックで呼び出されます。
とにかく、次のように想像してみてください。
OrderOpenTime() = 12:12:01 (12 H 12 MIN 1 SEC)
注文が開かれ、Orderclose()関数のパケットはメインコードのOrderSend()の後にあるので、注文を開いた直後にOrderClose()パケットで注文を閉じるための条件が満たされたかどうかをテストすることになります。
Time[0]は、このバーのオープン価格なので、一般的なロジックでは、注文が開かれた時間よりも小さくなければならない、注文は同じバーopen.Itの前に開くことができないので：12時12分00秒です。
だから、すべての手段によって。
真値を返すので、ordercloseがトリガーされます。スリッページなど何らかの理由で閉じることができない場合は、問題なく、start()が繰り返されます。
そして、次の繰り返しでは、Time[0]は100％注文のオープン時間より大きくなります。これは論理的なことで、最初のクローズに失敗すると、その後、start()が繰り返されるたびに他のOrderClose()が発生します。そして、私はstart()がすべてのティックで繰り返されると思っているので、より速く注文を閉じるための良い方法はないと思います。私はそれが明確に説明したと思います :)
あるバーの終値が 次のバーで繰り返されないことは非常に稀であり、必ずしもその始値が繰り返されるとは限らない ...