MT5ターミナルでインジケーター（ライン、矢印、ヒストグラム）が点滅するのはなぜですか？ - ページ 6 12345678910 新しいコメント Eugene Myzrov 2017.04.28 08:25 #51 Andrey Khatimlianskii: ある思いがよぎった。prev_calculated = 0 の場合、完全な再計算（および再描画）が行われる。この場合のためにOnCalculateプリントを最初に挿入してみて、点滅が起こったときにプリントが表示されるかどうかを確認してください。もしそうなら、端末がカウンターを0にリセットする原因を突き止める必要があります（それについてサービスデスクに手紙を書くことも可能です）。そうでない場合はさらに不具合となり、簡単なテストインジケーターと再生条件、短いデモビデオをサービスデスクに送ることができます。OnCalculate()関数に printを挿入するという同様の解決策を提案されたので、それを追加しましたが、ログには何も予期せぬものは現れず、新しいバーを受信して処理する通常のプロセスが存在します。カウンターはリセットされませんが、ブリンクは発生します。 Alexey Viktorov 2017.04.28 08:26 #52 Andrey Khatimlianskii:ある思いが湧いてきました。prev_calculated = 0 の場合、完全な再計算（と再描画）が行われます。この場合のためにOnCalculateプリントを先頭に挿入して、点滅時にプリントが表示されるかどうか試してみてください。もしそうなら、端末がカウンターを0にリセットする原因を突き止める必要があります（それについてサービスデスクに手紙を書くことも可能です）。そうでない場合は、さらに不具合と判断し、簡単なテストインジケーターと再生条件、短いデモビデオをサービスデスクに送ることができます。簡単な裏話です。少し前に、mql4からmql5へリアルタイムでティックアップとティックダウンを別々に収集するインジケータを書き直そうとしましたが、インジケータが定期的に既に蓄積されたデータをリセットするためうまくいきませんでした。 この問題をSDに相談したところ、リセットはprev_calculatedが0にリセットされて全体の履歴が再計算され、サーバとの接続損失により発生すると保証されました。昨日作った実験。まず、Print()を条件に入れて...。それを待たずに、人為的に接続の喪失を作り始めた。Print()は実行されるが、インジケータは点滅しない。また、チャート上でクリックし、コンテキストメニューから「更新」してprev_calculatedをゼロにしましたが、インジケータが点滅することはありません。ChartRedrawがインジケーターの再計算に どう影響するか見てみることにしましたが、結果は0 です。これは、インジケータ自体にも 、ChartRedrawの 呼び出しで並行して動作するインジケータにも、 何の影響も与えません。prev_calculatedに代わるものを探してみました。何らかのテクニカル 指標が呼び出された場合、prev_calculatedはBarsCalculated(handle)に置き換えることができますが、そうでない場合は...。が見つかりません。このような置き換えの場合、prev_calculatedがゼロになると、インジケータは再計算されず、計算が失われることはない。とにかく、役に立つものを見つけることができなかった...。これは、妄想のような推測です。数ティックが失われた後、多少の遅れをもってロードされ、その瞬間にウィンクが発生するということはありえないのでしょうか？ fxsaber 2017.04.28 08:55 #53 ティックに基づくこのヒストグラムの株式指標は、誰かのためにちらつきますか？一度だけ（マーケットオープン時）、CTRL+Dパネルのみで常時インジケータがちらつくのを見ることができましたが、ヒストグラム自体はちらつきが見られませんでした（おそらくGPU不足のため）。ビデオ録画の場合は再生ができませんでした。為替効果は、高速な市場で観察されるべきものです。証券取引所が始まるのを待つ必要があり、そうすれば、ほとんどの場合、ちらつきを記録することが可能になる。あるいは、端末を数時間の連続録画にかけるのもおすすめです。そして、ちらつきが特に目立つ部分を切り取ってください。 Stanislav Korotky 2017.04.28 11:56 #54 カウンターリセット（またはティックの「遡及」編集）は、ターミナルがチャートを再描画する唯一のケースであると誤解してはいけません。そこには、おそらく私たちの知らない別の要因がたくさん考慮されているのでしょう。この問題は、再現のランダム性と、通常サービスデスクで発生するコミュニケーションの難しさから、釘を刺しました。 Eugene Myzrov 2017.04.28 12:08 #55 Stanislav Korotky: カウンターのリセットだけが、端末がチャートを再描画する場合だと勘違いしてはいけない。そのロジックは、私たちが知らない他の多くの要素を考慮しているのでしょう。リプレイのランダム性と、通常サービスデスクで発生するコミュニケーションの難しさから、この問題に釘を刺しています。私も同じ結論に至っています。おそらく、これは社内の問題で、公表されることはなく、本当の理由はわからないだろう。そして、開発者はこの質問に対して暗に態度を表明したが、一度もこのスレッドに登場することはなかった。明確にできたはずなのに...。 Aleksey Vyazmikin 2017.05.21 09:34 #56 配信のZZインジケーターが数秒間オフラインで消えた......だから、刻みの問題じゃないんだよ。 Roman Vashchilin 2017.05.23 09:26 #57 Eugene Myzrov:OnCalculate()関数に printを挿入するという同様の解決策を提案されたので、それを追加しましたが、ログには何も予期せぬものは現れず、新しいバーを受信して処理する通常のプロセスが存在します。カウンターはリセットされないが、ブリンクは起こる。 前のページを読んでいないのですが、質問の答えは出ているのでしょうか？もしそうでなければ、バッファの数を増やしてみてください。 Aleksey Vyazmikin 2017.05.23 16:10 #58 Roman Vashchilin: 前のページを読んでいないのですが、疑問は解決されましたか？もしそうでない場合は、バッファの数を増やしてみてください。 バッファの数も標準ゾーンでは間違っているのでしょうか？ Eugene Myzrov 2017.05.24 13:47 #59 Roman Vashchilin: 前のページを読んでいないのですが、質問の答えは出ているのでしょうか？もしそうでなければ、バッファの数を増やしてみてください。なぜ「バッファの数が間違って立っている、だから点滅している」と思うのですか？ もし、2つのバッファと2つのアレイを使うのであれば、それに合わせて指定することになります。#property indicator_buffers 2 #property indicator_plots 2なぜ必要以上に、つまり2つ以上のバッファを指定する必要があるのでしょうか？ Roman Vashchilin 2017.05.24 20:23 #60 Eugene Myzrov:なぜ「バッファの数が間違って立っている、だから点滅している」と思うのですか？ もし、2つのバッファと2つのアレイを使うのであれば、それに合わせて指定することになります。なぜ必要以上に、つまり2つ以上のバッファを指定する必要があるのでしょうか？ また、一致していれば、変更する必要はありません。 12345678910 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
OnCalculate()関数に printを挿入するという同様の解決策を提案されたので、それを追加しましたが、ログには何も予期せぬものは現れず、新しいバーを受信して処理する通常のプロセスが存在します。カウンターはリセットされませんが、ブリンクは発生します。
ある思いが湧いてきました。
prev_calculated = 0 の場合、完全な再計算（と再描画）が行われます。この場合のためにOnCalculateプリントを先頭に挿入して、点滅時にプリントが表示されるかどうか試してみてください。
もしそうなら、端末がカウンターを0にリセットする原因を突き止める必要があります（それについてサービスデスクに手紙を書くことも可能です）。
そうでない場合は、さらに不具合と判断し、簡単なテストインジケーターと再生条件、短いデモビデオをサービスデスクに送ることができます。
簡単な裏話です。
少し前に、mql4からmql5へリアルタイムでティックアップとティックダウンを別々に収集するインジケータを書き直そうとしましたが、インジケータが定期的に既に蓄積されたデータをリセットするためうまくいきませんでした。 この問題をSDに相談したところ、リセットはprev_calculatedが0にリセットされて全体の履歴が再計算され、サーバとの接続損失により発生すると保証されました。
昨日作った実験。
まず、Print()を条件に入れて...。それを待たずに、人為的に接続の喪失を作り始めた。Print()は実行されるが、インジケータは点滅しない。
また、チャート上でクリックし、コンテキストメニューから「更新」してprev_calculatedをゼロにしましたが、インジケータが点滅することはありません。ChartRedrawがインジケーターの再計算に どう影響するか見てみることにしましたが、結果は0 です。これは、インジケータ自体にも 、ChartRedrawの 呼び出しで並行して動作するインジケータにも、 何の影響も与えません。
prev_calculatedに代わるものを探してみました。何らかのテクニカル 指標が呼び出された場合、prev_calculatedはBarsCalculated(handle)に置き換えることができますが、そうでない場合は...。が見つかりません。このような置き換えの場合、prev_calculatedがゼロになると、インジケータは再計算されず、計算が失われることはない。
とにかく、役に立つものを見つけることができなかった...。
これは、妄想のような推測です。
数ティックが失われた後、多少の遅れをもってロードされ、その瞬間にウィンクが発生するということはありえないのでしょうか？
ティックに基づくこのヒストグラムの株式指標は、誰かのためにちらつきますか？
一度だけ（マーケットオープン時）、CTRL+Dパネルのみで常時インジケータがちらつくのを見ることができましたが、ヒストグラム自体はちらつきが見られませんでした（おそらくGPU不足のため）。ビデオ録画の場合は再生ができませんでした。
為替効果は、高速な市場で観察されるべきものです。証券取引所が始まるのを待つ必要があり、そうすれば、ほとんどの場合、ちらつきを記録することが可能になる。あるいは、端末を数時間の連続録画にかけるのもおすすめです。そして、ちらつきが特に目立つ部分を切り取ってください。
私も同じ結論に至っています。おそらく、これは社内の問題で、公表されることはなく、本当の理由はわからないだろう。そして、開発者はこの質問に対して暗に態度を表明したが、一度もこのスレッドに登場することはなかった。明確にできたはずなのに...。
配信のZZインジケーターが数秒間オフラインで消えた......だから、刻みの問題じゃないんだよ。
OnCalculate()関数に printを挿入するという同様の解決策を提案されたので、それを追加しましたが、ログには何も予期せぬものは現れず、新しいバーを受信して処理する通常のプロセスが存在します。カウンターはリセットされないが、ブリンクは起こる。
前のページを読んでいないのですが、質問の答えは出ているのでしょうか？もしそうでなければ、バッファの数を増やしてみてください。
前のページを読んでいないのですが、疑問は解決されましたか？もしそうでない場合は、バッファの数を増やしてみてください。
なぜ「バッファの数が間違って立っている、だから点滅している」と思うのですか？ もし、2つのバッファと2つのアレイを使うのであれば、それに合わせて指定することになります。
なぜ必要以上に、つまり2つ以上のバッファを指定する必要があるのでしょうか？
なぜ「バッファの数が間違って立っている、だから点滅している」と思うのですか？ もし、2つのバッファと2つのアレイを使うのであれば、それに合わせて指定することになります。
なぜ必要以上に、つまり2つ以上のバッファを指定する必要があるのでしょうか？
また、一致していれば、変更する必要はありません。