オーダー変更時のエラー1 - ページ 6

新しいコメント
 
tara:
あなたはどのように投票しましたか？
今日は涼しかったので（＋15）、着の身着のまま出かけました。そして、気にならないので何もつっこまなかった。
 
アケラ ...
 
tara:
アケラ...

調子に乗るなよ!何が言いたいの？

 
borilunad:

すべてのチェックはループの前に行われ、各タイプに関連する条件と、Modify()のエラーチェックのみを行うこの関数を呼び出します。

他に何かあれば聞いてください、でももう夕食に行くので。;)

Boris、ありがとうございます、もちろんです。しかし、私のバグは間違った場所に埋まっていたことが判明したのです。別の場所にあったんです。同じ注文の出し方で送った後に修正があり、さらに同じティックで別の条件で修正があった。そのため、注文を開くと、そのティックにエラーが発生しました。また、それ以外の時間帯ではエラーはありませんでした。

さらに踏み込めば、絶対に条件が守られない場合、そこでストップロスやフリーフォール＋価格訂正をチェックする機能は正しいのですが、コンパイラカーブはなぜかそれを正しく処理したがりません。すべて印刷すると、すべてその通りになり、一段階上のものもすべてクリアになります。しかし、結果は出ませんでした。その機能を2つに切り分けたところ、すべてがうまくいくようになりました。

もちろん、この曲面が好きなわけではないのですが、今は我慢しています...。

 
hoz:

ボリス、もちろん、ありがとうございます。しかし、実は、埋葬する場所を間違えていたことが判明した。別の場所にあったんです。同じ方法で注文を出した後、修正があり、さらに同じティックで別の条件による修正がありました。そのため、注文を開くと、そのティックにエラーが発生しました。また、それ以外の時間帯ではエラーはありませんでした。

さらに踏み込めば、絶対に条件が守られない場合、そこでストップロスやフリーフォール＋価格訂正をチェックする機能は正しいのですが、コンパイラカーブはなぜかそれを正しく処理したがりません。すべて印刷すると、すべてその通りになり、一段階上のものもすべてクリアになります。しかし、結果は出なかった。その機能を2つにノコギリで切って、今、動いている。

もちろん、この曲面が好きなわけではないのですが、今は我慢しています...。

どういたしまして。私もすべてを整頓しているわけではありませんようやく別のEAを完成させました。一日中試しましたが、今になってようやくきちんと結合するようになりました。またRealでサプライズを用意する予定です。要は、粘り強さ、忍耐力、根気強さです
 
https://forum.mql4.com/ru/65622
 
azfaraon:
https://forum.mql4.com/ru/65622
教授本人に連絡することをお勧めしますあなたは彼のシステムのロジックを変更したいのですが、彼よりうまくできる人はいないでしょうし、他人のコードをいじってくれる人が見つかるとは思えません。特に、ほとんどの場合時代遅れで、無名の警備員による「セキュリティ」のためのものです
 

ボリス この機能では、さまざまな要素が考慮されていないことが問題です。例えば、トラッドウルフが許されるかどうか...。など私の修正機能には、このような文字列があります。

   while (IsTradeAllowed() == true)
      {
         if (!IsExpertEnabled() || IsStopped() || li_Cnt > 200)
         {
            CLogs.WriteLog (StringConcatenate ("Error: Trying to send order ", GetNameOP (fi_Type), " | Price: ", DToS (fd_Price), " NOT IsTradeContextBusy"));

            if (!IsExpertEnabled())
            {
               CLogs.WriteLog ("Permit ExpertEnabled !!!");
            }
            return (-1);
         }

これは例えばの話です。つまり、私が言いたいのは、簡潔であることが必ずしも便利ではないということです。結局のところ、これらのチェックはいずれにせよ実際のトレントに存在するものです。では、なぜブラックボックスに入れないのか？

と、もう考えないのでしょうか？その方が楽でもありますし...。

十分なプラットフォームがあれば、よりシンプルになります。私たちの場合、それはベストな選択ではありません。しかし、ある種の中間を見出すことは可能です。あまり長いコードではありませんが、空っぽでもありません。

 
hoz:

ボリス この機能では、さまざまな要素が考慮されていないことが問題です。例えば、トラッドウルフが許されるかどうか...。など私の修正機能には、このような文字列があります。

これは例えばの話です。つまり、私が言いたいのは、簡潔であることが必ずしも便利ではないということです。結局のところ、これらのチェックはいずれにせよ実際のトレントに存在するものです。では、なぜブラックボックスに入れないのか？

と、もう考えないのでしょうか？その方が楽でもあるし...。

十分なプラットフォームがあれば、よりシンプルになります。私たちの場合、それはベストな選択ではありません。しかし、ある種の中間を見出すことは可能です。あまり長いコードではありませんが、空っぽでもありません。

ビクター、私はポジションを開く前に取引の決着を チェックし、また十分なエクイティや他の多くのものをチェックしますが、機能ではなく、スタートにおいてですでは、なぜモディフィケーションでチェックするのか？
 
borilunad:
ビクター、私はポジションを開く前に取引を許可するチェックと、十分なエクイティと他の多くのもののチェックを持っていますが、機能ではなく、開始で!では、なぜモディフィケーションでチェックするのか？

ボリス 簡単なことだ。

まず、この場合、このチェックが必ず入るので、今後忘れることはないでしょう。

第二に、このチェックは非常に短い時間を必要とするため、コードの最適 化を与えることができず、処理の高速化にはつながらない。すなわち、「取引を許可する」にチェックを入れて関数を入力するか、入力してから「取引を許可する」にチェックを入れるか、どちらかです。

第三に、エクイティについては、別に実装するべきだという意見に賛成です。この部分をノコギリで切ってもらいました。そして、多くのものを取り除きました。さて、関数は全般的に短いです。

1234567
新しいコメント