Init()およびDeInit()実行シーケンス - ページ 5

 
Nikolai Semko:


確かにそれはわかります。一連の動作のロジックを聞いていたのです。そして、ここで私たちはそれを見逃しているのです。OnDeinitが先に実行されることもあれば(素人の理屈ではそうなるはず)、OnInitが先に実行されることもある。

その答えは、"For some time (a very short time) both copies of indicators exist in parallel " という行にあると実感しています。しかし、これでは疑問が晴れない。

OnInit関数は、プログラム中で最初に実行する必要があります。

OnInit -> OnDeinitのシーケンスが常に実行されない場合の例を教えてください。

 
Andrey Dik:

OnInit関数は、プログラムの中で最初に実行されることになっています。

OnInit -> OnDeinitが常に実行されない場合の例を教えてください。


テーマERROR.mq 5の作者が冒頭で あげた例を使うことができます。TFを切り替えて、Expertsタブでどうなるか確認します。

 
Nikolai Semko:


冒頭で 紹介したERROR.mq5の 例を使ってみましょう。

日中に使用する予定です。そして、あなた個人はすでに使っているのですか?
 
Andrey Dik:
その日のうちに試してみます。個人的にはまだ使っていないのですか?

もちろん、9ヶ月前にも使っています。このスレッドの8 番にある私のコメントを読んでみてください。
 
Stanislav Korotky:

えー、いや、そんな単純な話じゃないんです。インジケータは、チャート/図表という別のエンティティの内部に位置し、それに従属します(1対多の複雑な関係であることは承知していますが、要点は変わりません)。チャートには独自のライフサイクルがあり、そのライフサイクルには何らかの内部的なinit、deinitイベントがあり、これが指標のライフサイクルの境界となる。言い換えれば、指標はそのチャートより長生きすることはできないのです。チャートのdeinitは、すべてのインジケータのdeinitまたはdeinitのタイムアウトを待つ必要があります。このとき初めて、新しいタイムフレームのチャートのinitが開始され、そこから付属のインジケーターのinitを呼び出すことができます。

チャートは指標と同じ です。指標はチャートよりも「長持ち」する。

インディケータ/アドバイザーのOnInitの前に、グローバルオブジェクトのコンストラクタが実行されます。OnDeinitの後 - デストラクタ。したがって、OnInitとOnDeinitを任意のインジケータから削除することができます。

ただ、指標に関する自分の考えと現実が一致していないことが問題なのです。おそらく、この動作は、解決策を書くことができないいくつかのフリーランサーのために重要である.

このテーマについて、開発者が一歩踏み出すことを歓迎します。しかし、ここでは全く理解しやすい2つの視点が、当然のようにそれぞれの論理でぶつかり合っているのです。どちらも欠点が多いわけではありません。ただ、「こっちが正しい」と思う人もいれば、「あっちが正しい」と思う人もいるわけです。

 

もし、TF を変更する前に、ターミナルが古い TF からすべてのインジケータをアンロードするのを待ち、それから新しい TF を構築して初期化したとしたら、チャートがどれほど遅くなるか想像してみてください。

グラフィカル・オブジェクト(名前にTFの名前がない)の単純作業以外に、どのような状況でDeInit - Initシーケンスが重要になるのでしょうか?

 
Andrey Khatimlianskii:

もし、TF を変更する前に、ターミナルが古い TF からすべてのインジケータをアンロードするのを待ち、それから新しい TF を構築して初期化したとしたら、チャートがどれほど遅くなるか想像してみてください。

グラフィカル・オブジェクト(名前にTFの名前がない)の単純作業以外に、どのような状況でDeInit - Initシーケンスが重要になるのでしょうか?


+
 

もう一度言います。チャート上でタイムフレームやシンボルを変更すると、インジケータの新しいコピーが作成されます。新しいもの です。

指標の計算部分が履歴キャッシュに宿るのと同じ理由です。各タイムフレームには、バーのキャッシュがあります。タイムフレームを変更した場合、例えばEURUSD,M1をEURUSD,H1に変更した場合、キャッシュのM1には原因3(チャート変更)でイベントDeinitが送られ、しばらくするとこのインジケータはアンロードされるでしょう。もしこのインディケータが突然、理由3でDeinitを処理する時間がなかった場合、理由1(チャートクローズ)でDeinitされることになります。もし、この時点までにH1キャッシュが存在しなければ、作成される。その後、NEW インジケーターのコピーがH1キャッシュにロードされ、そこにInitイベントが送信される。インジケーターの新しいコピーは、死のうとしている前のコピーについて何も知らない。インジケーターの新しいコピーのすべての変数はきれいで、それらは新しく生まれたものです。

一つのシンボル内で時間軸の変更があった場合、初期化・非初期化の順番は原則的に予測可能である。最新のビルド1580をダウンロードしてください - 私たちはそこにいくつかのことを修正しました。しかし、シンボルを変更すると、純粋な形でスレッド間競争が発生し、初期化-初期化の順序を一義的に予測することができなくなります。異なる文字が異なるスレッドで処理されるため

ですから、トピックスターターへのヒントです。非初期化の原因から 導くこと。3であれば、グラフに配色を返す必要はない

 
TFを変更する際に、全てのDeinitを待ってから、インジケータを起動し、Initを実行することはできないのでしょうか?
 
Andrey Khatimlianskii:

もし、TF を変更する前に、ターミナルが古い TF からすべてのインジケータをアンロードするのを待ち、それから新しい TF を構築して初期化したとしたら、チャートがどれほど遅くなるか想像してみてください。

グラフィカルなオブジェクト(名前にTFの名前がない)を使った単純な作業は別として、DeInit - Initシーケンスはどんな場面で重要なのでしょうか?


なぜ遅いのでしょうか?インジケーターの書き方が間違っていなければ。よくできたインジケータの 場合、DeInitはかなり短時間で終了します。しかも、TFの切り替えはそれほど頻繁に行われる操作ではありません。特に深刻な場合(「間違った」指標の場合)には、TFを変更する際に1秒か2秒待つことができます。

したがって、TF切り替え時のブレーキについての議論は怪しさ満点である。さらに、まだ構築されていないTFに切り替えると、かなりの時間遅れが発生します。そして、誰もターミナルのブレーキに泣くことはない。