2013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: Тикет № 2; New_OOP = 1.34048; New_SL = 1.34125; New_TP = 1.333622013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: Тикет № 2; OrderOpenPrice() = 1.34048; OrderStopLoss() = 0.0; OrderTakeProfit() = 0.02013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: Тикет № 2; New_OOP = 1.34048; New_SL = 1.34125; New_TP = 1.333622013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: _LastError = 02013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: modify #2 sell limit 0.10 EURUSD at 1.34048 sl: 1.34125 tp: 1.33362 ok
2013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: OrderModify error 1
そしてその前に、上に示したように、テストがあるのです。
if ((ND (OrderOpenPrice()) != fd_OpenPrice) || ND ((OrderStopLoss()) != fd_NewSL) || (ND (OrderTakeProfit()) != fd_NewTP))
{
... Если какой-то из параметров отличается от нового, значит выполняется это условие...
}
ボリス 仮にそうだとすると......。想定しています。しかし、関数が注文を修正するために再送信する場合、有意差は修正されるべきです。そして、私の場合は、まったく修正しないのです。過去ログで見ても、見えてくるのはこうだ。
なぜ注文が送信されるのですか?正しいパラメータがなかったら、関数が吹っ飛んでしまうところだった......。OKという感じです...。...送信されました。すると、エラーがあることが判明し...。どのような理屈なのでしょうか。電源を入れたばかりなのに!Victorの場合、"ok "であれば、何らかのパラメータが変更されたことを意味し、エラー1は、何らかのパラメータが変更されると宣言されたが、変更されないことが判明したことを意味します。だからこそ、そのようなケースを避けるために、あなたのロジックを修正する必要があるのです。このような不正確なロジックはすべて、実際のマーケットでリクオートと多くのエラーを引き起こすことになります
私がこのようなプログラミングスタイルをとらないのは、すべてがあちこちに散らばっていることをご存じだからです。プログラムを論理的なスクリプトとして書き、すべてのイベントが順次展開され、何かを探して探し回ることなく、すべての条件が常に手元にある状態です。そして、最終的な動作やエラーチェックは外部関数で行って います。
しかし、あなたの場合、何があってどこにチェックが入っているのかが素人には不明で、すべてが隠されていて、前提条件をチェックしたかどうかを推測しなければならないのです今の私のような言葉ですが、あなたのプログラムでは意味が伝わらないのです。明確で簡潔であるべきです
ボリス もちろん、すべてを一度に把握できているわけではないことは承知しています。しかし、修正関数の直前の入力パラメータはドッキングされています。スクリーンショットを投げたところです。PLOは現行と 新が あり、SLとTPがあります。そして、それらはすべて異なっている。すべてが近くにあるのに、なぜ細かいことを言わなければならないのか。無印で、パラメータが違うことがわかると、確かに違うということになります。それとも、印刷物も信用しないほうがいいのでしょうか?
そしてその前に、上に示したように、テストがあるのです。
もっと具体的に教えてください。上のほうには、作り話を始めた道化師が何人かいる。どうやら、私が尋ねていることを理解できない、あるいは理解しようとしないようだ。だから、彼らは意味もなく笑っているんです。しかし、その疑問は興味深いものです。
例えば、OrderModify()に別の型のパラメータや間違った数量を挿入すると、一度にエラーが発生します。そして、ここで実行され、OKのように表示されますが、その後、パラメータが変更されていないことが判明します。
問題は、そこで何が問題なのか、どうすればわかるのか、ということです。自分の機能を並べました。そこですべてがクリアになるはずです。これです。
わざと全部の行をコメントアウトしたんです。コードを台無しにするだけかもしれません。何かコメントがあれば、ご協力お願いします。
ボリス もちろん、すべてを一度に把握できているわけではないことは承知しています。しかし、修正関数の直前の入力パラメータはドッキングされています。スクリーンショットを投げたところです。PLOは現行と 新が あり、SLとTPがあります。そして、それらはすべて異なっている。すべてが近くにあるのに、なぜ細かいことを言わなければならないのか。無印で、パラメータが違うことがわかると、確かに違うということになります。それとも、印刷物も信用しないほうがいいのでしょうか?
そしてその前に、上に示したように、テストがあるのです。
すべて申し訳ありませんが、orderパラメータが互いに混同されないようにする条件がループ内に見当たらないため、意味を理解することができないのです
エラーがあるということは、どこかで論理的な間違いを犯していることを物語っています。ただ、「プログラムが動く」とも書いてありますが、プログラムの質が気になるところです
すみません、orderパラメータが互いに混同されないようにする条件がループ内に見当たらないので、これを把握することができないのです
エラーがあるということは、どこかで論理的な間違いを犯していることを物語っています。ただ、「プログラムが動く」とも書いてありますが、プログラムの質が気になるところです
注文に関するすべての操作は、ループの中で行われますここで、先に引用したfOrderModify()というメソッドが呼び出されるわけです。
そこですべてを見ることができる...また、ループの各反復の後、エラーがクリア されていることがわかります。したがって、前の順番でエラーがあったとしても、その事実が次の順番に飛び火しないことが保証されています(もちろん、その値のことです)。
どこまで簡単にできるのか?とても簡単なことなのですが・・・。
メッセージを 発見しました。
同じ端末のバグです。こんなバグは初めてです。保留中の注文の3つのパラメータ(OOP、SL、TP)を変更することは、今まで試したことがありません。でも、そうせざるを得なかったんです。そして、バグに遭遇してしまった。
なるほど、例えば、建値とStop Lossが変わっていない代わりに、同じ値が表示されても、Take Pointが変わっている場合は、そのように表示されるのですね。これもエラーの原因になるのでしょうか?すると、文書が曲がっていることが判明。そして、この点が支持されていないとか、なんだとか。
メッセージを 発見しました。
同じ端末のバグです。こんなバグは初めてです。今まで、保留中の注文の3つのパラメータ(OOP、SL、TP)を変更しようとしたことはありませんでした。でも、そうせざるを得なかったんです。そして、バグに遭遇してしまった。
なるほど、例えば、建値とStop Lossが変わっていない代わりに、同じ値が表示されても、Take Pointが変わっている場合は、そのように表示されるのですね。これもエラーの原因になるのでしょうか?すると、文書が曲がっていることが判明。そして、この点が支持されていないとか、なんだとか。
距離も1ティックごとに確認するのですか?私はずっと以前から、TFバーのオープニングで注文を出し、M1のバーのオープニングでのみ注文を修正・決済するというルールを採用しています。上記のコードは、すべてを含んでいるようで、具体的なものが何もない進捗報告書を思い出させるものです特定の条件によってすべてのアクションを定義するようなループは見当たりません。何も修正しない、それなら修正しなければいい、エラーは出ない、というループしか見えません。
Renat の重要な観察によれば、エラーはグローバルに行うべきこととローカルに行うべきことの混乱から生じることがあり、エラーは常に後者で、以前のものは関数の終了に関与せずにリセットされるのだそうです
距離も1刻みで確認するのか!?
いいえ!条件を満たした場合のみ、修正を許可しています。この場合、算出されたレベルを変更することが修正の条件となる。ただ、それだけなんです。
シンプルに?ちょっと...
昔、TFのバーオープンで注文を出し、M1のバーオープンでだけ修正・決済するルールを作ったんだ。上記のコードは、すべてを含んでいるようで、具体的なものは何もない、進捗報告書を思い出させます特定の条件によってすべてのアクションを定義するようなループは見当たりません。何も修正しないでください、それなら修正しないでください、エラーはありません、というループしか見えません。
M1のオープン時のみ修正するというのは、私も同じような考えを持っていました。しかし、M1でこのデータを確認する必要がない場面もある。例えば、すでに計算済みの水準でストップを引いている。それから、上に示したように、OnInit()関数でチェックを入れています。
すなわち、レベルが変更された場合、それは...を修正します。これにより、不必要な修正作業を回避することができます。いわば、タイマーではなく、信号による改造です。ここで理解できたか?特定の条件によってすべてのアクションを定義するループはないのか!何も修正しないで、修正しないだけで、エラーも出ないというループしか見られません。
外で全部脱がせています。何がわからないのか...。:(
Renat の重要な指摘に注意してください。エラーは、グローバルに行うべきこととローカルに行うべきことの混乱から来るもので、エラーは常に後者です。
そして、それは解決されなかったし、これからもされないようです。開発者が怠け者なのでは?もし私がエラーで正しく動作していないのであれば、レナートを含む誰かが、私が間違っていると言うだけでなく、コードをつつくことができたはずです。
結局のところ、修正するパラメータの新しい値と現在の値が修正関数の前に出力されれば、これらの値が存在することは明らかです。なぜ、どこか高いところに行くのか?値があり、エラーがないことがわかります(エラーがあるためそこに印刷しました)。論理的にはすべてうまくいくということです。つまり、修正機能の不具合ですね。
いいえ!条件を満たした場合のみ、修正を許可しています。この場合、算出されたレベルを変更することが修正の条件となる。ただ、それだけなんです。
シンプルに?ちょっと...
M1のオープニングだけ修正するというのは、私も同じようなことを考えていましたし、あらかじめ決められた値で修正するのであれば、これは適用できます。しかし、M1でこのデータを確認する必要がない状況もある。例えば、すでに計算済みの水準でストップを引いている。それから、上に示したように、OnInit()関数の中にチェックが入っています。
すなわち、レベルが変更された場合、それは...を修正します。これにより、不必要な修正作業を回避することができます。いわば、タイマーではなく、信号による改造です。ここで理解できたか?そこですべてを解き放ちました。何がわからないのか...。:(
この問題は、私だけでなく、多くの人が経験していることです。ここで一例を・・・。そして、それは解決されていないし、これからもされないようです。開発者が怠け者なのでは?もし私がエラーで正しく動作していない場合、Renatを含む誰かがコードをつつくことができ、私が間違っていると言うだけではありません。
結局のところ、修正するパラメータの新しい値と現在の値が修正関数の前に出力されれば、これらの値が存在することは明らかです。なぜ、どこか高いところに行くのか?値があり、エラーがないことは明らかです(エラーがあるためそこに印刷しました)。論理的にはすべてうまくいくということです。つまり、改造機能に不具合があるわけです。
この例はすでに見ています。しかし、どんな条件でも、これ以上のものはないというまで適用しなければならないのです。あなたのコードでは説得力がない。これから昼食をとってから、SLの設定、B/Sへの変換、modify関数を1回呼び出すだけのトローリングで問題なく動作するループの例を挙げますと、エラーは、仕事で突然発生してもテスターで発生しないように処理されています。
Modify()関数は必要ですか?
結局のところ、修正するパラメータの新しい値と現在の値が修正関数の前に印刷されていれば、これらの値があることは明らかである。なぜ、どこか高いところに行くのか?値があり、エラーがないことは明らかです(エラーがあるためそこに印刷しました)。論理的にはすべてうまくいくということです。つまり、修正機能の不具合ですね。
Victorさん、保留ポジションのSLとTPを修正したのはなぜですか?一般的には、ポジションを建てた 後にSLを設定し、SLをB/Sに移した後にTPを設定するのが理にかなっているのだそうですでは、なぜ無駄にサーバーに迷惑をかけるのか、なぜこんな面倒なことをしなければならないのか!?
コードを最小限にして単純化し、速く明確に動作するようにしなければなりません。そうすれば、市場の気まぐれで微調整することも簡単になるでしょう市場の実情に合わせたニュアンスでじっくり考えてみてください