Если в MT изменить таймфрейм или имя символа чарта, то все индикаторы на чарте выгрузятся с чарта и загрузятся на него снова. При этом, в отличие от MT4, в MT5 последовательность выгрузиться/загрузиться не определена из-за особенности внутренней архитектуры. Данное обстоятельство иногда вызывает не сразу очевидные проблемы, связанные с тем, что...
では、そのような構造で非常に高速なインジケータが可能になるのでしょうか？
もっと言えば、OnCalculateは毎回のtickで 呼ばれるのではなく、tickのパックの後に呼ばれるでしょう。
もしそうなら、これは素晴らしいニュースです。
私たちは、#property tester_everytick_calculateフラグを含まないインジケータに、各ティックではなく、ティックのパックの受信に基づく計算モードを含めるというアイデアを持っています。
これにより、指標によっては1ティックごとの処理が保証される可能性を残しながら、遅刻の問題を根本的に解決することができます。
もうひとつの解決策を提案します。
シンボルインフォティック
指定されたシンボルの現在の価格をMqlTick型の変数で返します。
パラメータ
戻り値
そうすると、OnCalculateでは、次のような構文だけを書けばよいことになります。
このソリューションは、より柔軟で便利な使い方と実装が可能でしょう。
SZY カレントとインジケータのティック数を取得できるようなティック番号の設定があると良い。しかし、このバリエーションは開発者にとってはより困難なものです。ですから、おそらく、必要ないのでしょう。
別の解決策を提案します。
もし開発者が何もしなくても（ちなみにこれは非常に良い選択肢です）、この方法ですべてのブレーキをバイパスすることが可能です。
もし開発者が何もしなければ（ちなみにこれは非常に良い選択肢です）、次の方法で今あるすべてのブレーキを回避することが可能です。
まあ、バーの途中のテロップは要らない、どうせ強制的にスキップされるし。mqlによる実装を待とう。
まあ、バーの途中のテロップは要らない、どうせ強制的にスキップされるし。mqlの実装を待とう。
正直、理解できない。なぜ、被曝者が自分で解決策を書けなかったのか？
また、なぜ開発者がここで何かを変えなければならないのでしょうか？
このソリューションは、Init_Syncで 実装されているように、mqh-fileとして実装し、任意のインジケータに接続することが可能です。しかし、そのためには、あまり目立たない多くのコードが必要です。そして、ここにあるのはほんの数行です。
再接続通信後の他人の不可視時間帯の凍結更新を整理して修正しました。再接続後のキャッシュの状態が正しくないことが原因でした。
ベータ版 1946年版は、ヘルプ→デスクトップアップデートの確認→最新ベータ版から入手可能です。
Rinatさん、3日間のテストは問題なし、ありがとうございました。
正直なところ、被曝者が自分で解決策を書けない理由がわからないのですが？
そして、なぜ開発者がここで何かを変えなければならないのか。
インジケータに入力されるティックの数はどのような方法でも変更できず、新しいバーまでインジケータ内でスキップされます。インジケータが長い時間カウントしている場合、ティックはとにかくスキップされます。どうにかして現実に適応しなければならない。
1つのシンボルのピーク値が毎分800ティックだとすると、複数のシンボルの合成では、すでに毎分2300ティックになります。合成されたものを1つ、そこからシンボルを1つ開くと、1分間に〜3000ティックがピークになります。同じ合成、同じシンボルの別のタイムフレームを追加すると......よし、Elderの画面は3つだったから、1分間に〜9000ティック、1秒間に150ティックになるんだ。Rinatはすでにパフォーマンスの問題について書いています。マルチシンボルのmtfインジケータに毎秒150ティックのアイドリングストップが必要なのに、すべてのtfシンボルに毎分1-nティックが必要なのはなぜですか？同様に、mqlのホスティングの利点は、ホストシステムからのオーバーヘッドがなく、端末はインジケータとEAのみ同じホストであることです。RSI(3) + EMA(5) + EMA(7) という指標計算 であれば、今後10年間はもちろん問題ないでしょう。
合成（実際はターミナルからのマルチシンボル表示）において、開発者はどうにかしていくつかのシンボルを貼り付けることを思いついたのだが、なぜこのシステムの要素（完璧でもないと仮定しよう）をプログラマーの職人技レベルでインジケーターに複製しなければならないのか。システムを簡略化できるのであれば、なぜそうしないのか？地球がまだ三頭の象の上に立っていた頃、5秒計は何の意味もなく発明されたわけではありません。
タイムフレーム5秒、ヒストリーなし、ティックは5秒に一度だけ、あらゆる種類のソリューションをテストするために導入することができます（5Sでのみ動作するようにいくつかのプレフィックスを持つ指標をコンパイル、他の指標はその上で動作しません）-ターミナルの既存の思想は変わりませんので、我々はソリューションを変更し修正することができ、テスト中に最適な/最適解が形成されるでしょう。
(LMSからライブラリ開発、合成樹脂、戸建て用窓などデベロッパー）。
たとえ1分間に100万回の刻み目があったとしても、この解決 策が実行不可能になるわけではありません。
1分間に100万回刻んでも、解決 できないことはない。
問題は、ソリューションの作業性ではありません。未知の数のティックが見逃された前に、到達したティックごとにインジケータを呼び出すことの合理性は、その上、ティックのいくつかの陳腐化を考慮していますか？もし、何かが（負荷の増加に伴って）スキップされ、その刻みの関連性がわからない場合、この状況は解析上の問題を解決しない - そうでなければ、なぜそれを気にするのか。一般的に、指標へのティックの流れを禁止し、5秒に一度プラットフォームから指標にティックを残す - 毎分12ティック、それは十分です。
問題は、ソリューションの作業性ではありません。ティックの陳腐化以外に、未知数のティックが見逃される前に、到達したティックごとにインジケータを呼び出すことの合理性は、「？もし、何かが（負荷の増加に伴って）スキップされ、その刻みの関連性がわからない場合、この状況は解析上の問題を解決しない - そうでなければ、なぜそれを気にするのか。一般的に、指標に刻みの流れは禁止されるべきである、5秒ごとにプラットフォームから来る刻みは残すべきである - 毎分12刻み、それは十分です。
バカの一つ覚え。