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

 
Andrey Dik:

コピーに移すデータは常に最新にしておくこと、イニシャルの時だけでなく、常に最新にしておくこと、とはっきり書きました。


Andrey、あなたは冗談を言っているのか、それとも本当に理解していないのか、インジケーターの変数や配列に保存されている実際のデータは、TFを変更すると、すべての詳細とインジケーターのコピーが削除されるため、無関係になるのです。Expert Advisorでは、もちろん再初期化がないので、すべてがシンプルです。
 
Nikolai Semko:

TFを変更すると、インジケータの変数や配列に格納されている実際のデータは、その詳細がすべて削除されるため、すべて無意味になることを冗談か理解されていないのでしょう。もちろん、Expertsでは、再初期化がないので、すべてがシンプルです。

いいえ、そうではありません。

私の言っていることが理解できないのですね。

例えば、あるデータセットがあり、それをインジケータの別のコピーに転送する必要があります(チャート上に投げられた別のインジケータでも、TFが変更されたときの新しいインジケータのコピーでも、どちらでもかまいません)。このインジケータは何かを計算し、この何かが他のインジケータに適用されるたびに、このインジケータは更新されるはずです。その都度このデータベースは、データ量や必要なデータ転送速度に応じて、さまざまな場所に保存することができます。このデータは、初期化されたときだけでなく、データに変更が加えられた後、必要なときに更新される必要がある。それがコツです。複雑なことは何もありません。インジケーターのローカル 変数にデータを格納するのではなく、データが再計算されるたびにデータをリセット/更新することです。

しかし、グラフィカルなオブジェクトを使えば、とてもシンプルです。

 
Nikolai Semko:

Expert Advisorでは、もちろん再初期化がないので、すべてがシンプルです。
Expert Advisors では「再初期化」がありますが、ローカル変数は すべて保存されます。しかし、上で書いたのはそれ以外のこと、つまり、非初期化のときだけでなく、ローカルデータを変更するたびに外部ストレージに転送する必要がある場合の保存についてです。
 
Andrey Dik:

いいえ、そうではありません。

私の言っていることが理解できないのですね。

例えば、あるデータセットがあり、それをインジケータの別のコピーに転送する必要があります(チャート上に投げられた別のインジケータでも、TFが変更されたときの新しいインジケータのコピーでも、どちらでもかまいません)。このインジケータは何かを計算し、この何かが他のインジケータに適用されるたびに、このインジケータは更新されるはずです。その都度このデータベースは、データ量や必要な通信速度に応じて、さまざまな場所に保存することができます。このデータは、初期化されたときだけでなく、データに変更が加えられた後、必要なときに更新される必要がある。それがコツです。複雑なことは何もありません。ローカルな インジケータ変数にデータを保存するのではなく、データが再計算されるたびにリセット/更新されるのです。

また、グラフィカルなオブジェクトの場合は、非常にシンプルで、説明する必要すらありません。


何もかもが複雑であるというのは、非常に議論の余地がありますね。 この製品で 実装したことを、簡単なウェービングマシンの例で本当に再現してみてください。リストホイールでは、マウスで期間を変更し、その後、TFを変更すると、変更が保存されている必要があり、ウィンドウ内のいくつかのインジケータを使用することができます。そして、何も複雑なことはないことがおわかりいただけると思います。そして、配列を渡す必要がある場合。そして、その「シンプルさ」を実感してください。おそらく、まだ実装していなければ、私自身もそう思っているはずです。
 
Nikolai Semko:

何も難しいことはないというのは、非常に議論の余地があります。 この製品で 実装したことを、シンプルなレッカーの例で本当に再現してみてください。リストホイールではマウスで期間を変更し、TFを変更したら変更を保存する必要があり、ウィンドウ内で複数のインジケータを使用することが可能です。そして、何も複雑なことはないことがおわかりいただけると思います。そして、配列を渡す必要がある場合。そして、その「シンプルさ」を実感してください。

EAの変数はすべて再初期化時に保存されることを最近知りました。つまり、プログラムは他のプログラムについて何も知らない、そのためにはそのinitとdeinitしかない、プログラムは他のプログラムのinitとdeinitについて知ってはいけないと仮定して、EAを指標と同じ方法で書きました。

このため、プログラムをアンロードしたり再起動する際のininitとdeinitの時間的整合性は、いつかは変わる可能性があるということで、以前は全く当てにしていませんでした(1580年には変わっています)。文書化されていないバグやプラットフォームの未来に依存することは、将来的に裏目に出る可能性があります。

また、私の実務では、ユーザーのアクションに応じて動的に可視化を変更し、イベントから交換ファイルまで、あらゆるものを適用する製品もあります。チャート上には原則として1よりはるかに多くのインジケータがあり、5のインジケータバッファは無制限で、起動中にパラメータとして作成することができます。つまり、私たちはクリエイティブな人間ですから、3種類のプログラムの特性を考慮しつつ、柔軟なアプローチで課題を解決する必要がありますが、プラットフォーム開発者は、プラットフォームのグローバルなタスクと比較して、小さな困難よりも重要な別の課題に取り組んでいるのです。

プラットフォームには本当に重要な欠陥があり、それについて彼らはあまり語らないか、全く語らない。それは「initとdeinit」という遠回しな問題よりもずっと重要なことである。

 
Slawa:

タイムフレームが下方に切り替わった場合は、まず最下位(新タイムフレーム)のOnInitを行い、次に最上位(旧タイムフレーム)のOnDeinitを行います。

スイッチが上に行けば、その逆もしかり。まず、低い(古い)タイムフレームでOnDeinitを行い、次に高い(新しい)タイムフレームでOnInitを行います。

ここで注意しなければならないのは、キャッシュは最も低いタイムフレームから最も高いタイムフレームまで処理されるということです

これはひどいな。アプリケーションのプログラマーは、そんなシステム的なことは考えてはいけない。プラットフォームは内部で好きなようにキャッシュを処理することができますが、MQLレベルでは、潜在的な副作用なしに、すべてを単一のイベントコントラクトに透過的に持ってくる必要があります。効率性を考慮し、誰もが自分自身で問題を回避できる可能性があると主張する言及はすべて、単に受け入れがたいものです。効果的かつ便利に(一般的にこの熊手を踏む可能性を除く)、きっぱりと両立させることができるのです。
 
Stanislav Korotky:
これはひどいな。 アプリケーションのプログラマーは、そんなシステム的な ことは考えてはいけないのです。プラットフォームは内部的にどのようにでもキャッシュを処理することができますが、MQLレベルでは、潜在的な副作用なしに、透過的にすべてを単一のイベントコントラクトにまとめなければならないのです。効率性を考慮し、誰もが自分自身で問題を回避できる可能性があると主張する言及はすべて、単に受け入れがたいものです。効果的かつ便利に(この熊手を踏む可能性を完全に排除する)、一挙に行うことが可能です。

そうです、そうしてはいけないのです。例えば、Total Commanderを実行するわけです。なぜ、WindowsがRAMへのTCコピーのアップロード/ダウンロードの「正しい」順序を管理することをMicrosoftに要求するのでしょうか?それはOSの懸念事項なのでしょうか?

OSの懸念は、TCが他のTCと干渉しないことであり、そこでRAMで何をしようが、ファイルを交換しようが、それは彼らのビジネスである。

"そうだと思います!"(c) Mimino, 1977.

 
Nikolai Semko:

以上、要約してまとめたいと思います。では、MT5の1580ビルド(現在のビルド1571)のリリースを前に、何があるのでしょうか?

インジケータでは、Expert Advisorと異なり、TFが変わると「前のコピーのことを何も知らない新しいコピーが作成される」 ため、すべての変数が再初期化されるほか、古いTFのOnDeinitと新しいTFのOnInitの実行順序が、TFが「上」「下」にかかわらず予測できない(スラバさんの話逆の実践です)この関連で、プログラマーは多くの問題や不確実性を抱えている。例えば、
- OnInitで何かのインジケータを作成するときにこのトピックを読んでいないプログラマは、この名前でオブジェクトの作成前に論理的にチェックする、オブジェクトを作成します。また、OnDeinitでこのオブジェクトの削除を規定するのが論理的である。TFを変更した場合、最初に新しいTFのOnInitを実行し、オブジェクトの存在を確認すると、既に存在していることが判明し、作成されない。その後、旧TFのOnDeinitが実行され、オブジェクトは削除される。プログラマーはショックを受けている。私のモノはどこにあるのか、なぜなくなったのか。次にTFが変更されたとき、OnInitとOnDeinitの順序が異なるときに、オブジェクトが削除されないと、彼はさらに混乱することになる。削除されたり、削除されなかったり...。長い研究の後、サービスデスク、古いものについてのフォーラムで新しいトピックに対処するために開始されます。
これは最も単純な状況に過ぎない。この機能はドキュメントに記載されておらず、フォーラムで読むしかないため、他の人もいるでしょう。
何か特別なものを作り、TFを変更したときに、インジケータの古いコピーから新しいコピーにいくつかのパラメータを渡したい場合、初期化および非初期化操作の順序が予測できないため、OnDeinitを使用することはできません。私
の意見では、この場合の最善の解決策は、次のツールを使用することです: ピクセル配列とResourceReadImageに基づいてResourceCreateが、それは非常に面倒で、あなたが1つのウィンドウで複数の同一の指標を使用する場合、リソースの競合の世話をする必要があり、別のコピーに送信したいデータが非初期化リソースにそれを保存する必要が毎回、TFの変更の可能性が時間は、アプリケーションに知られていないためです。ずいぶん前に(この製品などで)実装したことがあるので、よくわかるんです。ファイルや端末のグローバル変数を使ったデータ転送の実装は、あまり成功したとは言えない(IMHO)。

もし新しいビルド1580がSlavaの言うような ものになるなら、古いコピーのインジケータの非初期化は新しいインジケータの初期化の後に行われるので、この作業は簡単にはならないでしょう。しかし、不安はないでしょう。

この問題を解決しようとしているのですから、開発者が注意を払ったことを期待せざるを得ません。
新築を待ち望んでいます。


この処理機能はドキュメントに記載されなければならず、そうでなければ新規参入者がこの問題に直面し、フォーラムに解決策を探しに来ることになる、という点には完全に同意します。(TerminalやMQLのドキュメントですぐに伝えることができるのに、なぜ)。

また、ログは事象の全体像を示すものではなく、その一部であることをドキュメントに追記する。全貌は過去ログをご覧ください。

残りについては後ほど・・・。

 
Nikolai Semko:

以上、要約してまとめたいと思います。では、MT5の1580ビルド(現在のビルド1571)のリリースを前に、何があるのでしょうか?

インジケータでは、Expert Advisorと異なり、TFが変わると「前のコピーのことを何も知らない新しいコピーが作成される」 ため、すべての変数が再初期化されるほか、古いTFのOnDeinitと新しいTFのOnInitの実行順序が、TFが「上」「下」にかかわらず予測できない(スラバさんの話逆の実践です)この関連で、プログラマーは多くの問題や不確実性を抱えている。例えば、
- OnInitで何かのインジケータを作るときに、このトピックを読んでいないプログラマは、この名前でオブジェクトの作成前に論理的にチェックする、オブジェクトを作成します。また、OnDeinitでこのオブジェクトの削除を規定するのが論理的である。TFを変更した場合、最初に新しいTFのOnInitを実行し、オブジェクトの存在を確認すると、既に存在していることが判明し、作成されない。その後、古いTFのOnDeinitが実行され、オブジェクトが削除される。プログラマーはショックを受けている。私のモノはどこにあるのか、なぜなくなったのか。次にTFが変更されたとき、OnInitとOnDeinitの順序が異なるときに、オブジェクトが削除されないと、彼はさらに混乱することになる。削除されたり、削除されなかったり...。長い研究の後、サービスデスク、古いものについてのフォーラムで新しいスレッドに対処するために開始されます。
これは最も単純な状況に過ぎない。この機能はドキュメントに記載されておらず、フォーラムで読むしかないため、他の人もいるでしょう。
何か特別なものを作り、TFを変更したときに、インジケータの古いコピーから新しいコピーにいくつかのパラメータを渡したい場合、初期化および非初期化操作の順序が予測できないため、OnDeinitを使用することはできません。私
の意見では、この場合の最善の解決策は、次のツールを使用することです: ピクセル配列とResourceReadImageに基づいてResourceCreateが、それは非常に面倒で、あなたが1つのウィンドウで複数の同一の指標を使用する場合、リソースの競合の世話をする必要があり、別のコピーに送信したいデータが非初期化リソースにそれを保存する必要が毎回、TFの変更の可能性が時間は、アプリケーションに知られていないためです。ずいぶん前に(この製品などで)実装したことがあるので、よくわかるんです。ファイルや端末のグローバル変数を使ったデータ転送の実装は、あまり成功したとは言えない(IMHO)。

もし新しいビルド1580がSlavaの言うような ものになるなら、古いコピーのインジケータの非初期化は新しいインジケータの初期化の後に行われるので、この作業は簡単にはならないでしょう。しかし、少なくとも不安はないでしょう。

この問題を解決しようとするのですから、開発者が注意を払ったことを望みます。
新築を待ち望んでいます。

TFを切り替えてもExpert Advisorは正常に動作し、この状況でのインジケータは全く異なる動作をします。

 
Nikolai Semko:
この文書化されていない機能を認識し、最も単純なケースであるグラフのみを扱うのであれば問題ありません。オブジェクトを作成します。この機能を知らない人は、このフォーラムのこのトピックはごく一部のプログラマーにしか読まれないと思うので、すべてのニュアンスを理解するのに時間がかかるのはかわいそう だと思います。本質を理解する前に、このような事態に陥ってしまったのです。
そして、そんなつまらないことで無駄な言い争いをして時間を浪費するのは申し訳ないと思わないのか?