Jose Francisco Casado Fernandez: そうです、私が言っていたことです。そうしたら、うまくいったのですが、最初のStop Lossを 修正すると、同じPOSITION_IDを持たない新しい注文が生成されます。なぜなんでしょう。私は、それがバグだと思います。ありがとうございます。
Jose Francisco Casado Fernandez: そうです、私が言っていたのはそういうことです。そうしたら、うまくいったのですが、最初のStop Lossを 修正すると、同じPOSITION_IDを持たない新しい注文が生成されます。なぜなんでしょう。私は、それがバグだと思います。ありがとうございました。
スリッページはどうなっていますか？
そうです、私が言っていたことです。そうしたら、うまくいったのですが、最初のStop Lossを 修正すると、同じPOSITION_IDを持たない新しい注文が生成されます。なぜなんでしょう。私は、それがバグだと思います。ありがとうございます。
注文がクローズして おり、 クローズ価格は HystoryDealGetDouble(ticket, DEAL_PRICE) になって いるので、 スリッページを見る必要は ない。
もし、注文が クローズになって おらず、 クローズ 注文を 出す場合は、エラーに ならない ように、 スリッページを 考慮 する必要があります。
注文がクローズして おり、 クローズ価格は HystoryDealGetDouble(ticket, DEAL_PRICE) に あるので、 スリッページを見る必要は ない。
もし、注文が クローズして いない状態で、 クローズ する 注文を 出した場合、 どの程度の スリッページに なるかを考慮 し、 エラーに ならないように 再クオート する必要があります。
ついていけるか不安です。
HistoryOrderGetDouble(ticket,ORDER_SL)がストップロスになります。
SLが発動すると、スリッページが発生します。
HistoryDealGetDouble(ticket,DEAL_PRICE) は実際の価格が表示され、スリッページに遭遇したかどうかがわかります。
スリッページがあった場合、ORDER_SL == DEAL_PRICEという単純な比較は失敗するのでは?
そうです、私が言っていたのはそういうことです。そうしたら、うまくいったのですが、最初のStop Lossを 修正すると、同じPOSITION_IDを持たない新しい注文が生成されます。なぜなんでしょう。私は、それがバグだと思います。ありがとうございました。
SL/TPを変更する命令は、履歴に全く残りません。だから、ここで何を言っているのかよくわからない？
そして、実際にSL/TPが発動された結果の注文には、SL/TPが含まれていない。
<=は買い、>=は売りの場合です。
ついていけるか不安です。
HistoryOrderGetDouble(ticket,ORDER_SL)がストップロスになります。
SLが発動すると、スリッページが発生します。
HistoryDealGetDouble(ticket,DEAL_PRICE) は実際の価格が表示され、スリッページに遭遇したかどうかがわかります。
スリッページがあった場合、ORDER_SL == DEAL_PRICEの単純比較は失敗するのでは?
私の理解が正しければ、それは正確ではありません。実際の市場では、SL（またはTP）により、ポジションSL（またはTP）とは異なる価格で注文が閉じられることがあります。
Bid > close_price+spread や Ask < close_price-spread の場合はどうでしょうか？
スプレッド != デビエーション (スリッページ)
偏差のパラメータを 取得できないのは残念です。
おそらく妥当な妥協点は、（EAが注文を出したと仮定して）DEAL_PRICEが ORDER_SL± deviationのウィンドウ内にあったかどうかをチェックすることでしょう。
そうですね、Bid > close_price+spread や Ask < close_price-spread の場合はどうでしょう。