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

[Ihor Herasko]

Andrey Dik:

以上、嘆きが始まりました...。

あなたが求めているものは、まさに通常のデスクトップアプリケーションにはないものです。

アプリには何が入っていないのですか？シンクロナイズ？)))

もし開発者が、すでに「箱から出している」これらの機能をすべて行わなければ、MQLプログラムの書き手は、セキュリティであれ実行速度であれ、デスクトップ開発のあらゆる魅力に絶えず直面することになります。

これは事実無根の科学的推論に過ぎない。MT4では、OnInit()とDeInit()を連続して行うことでインジケータを動作させます。欠点は、すべてのインジケータが1つのスレッドで動作することです。MT5でも必要なインジケータを 適切に記述 することで解決します。とはいえ、MT5がなくなったわけではなく、とにかく1つのチャートのインジケータは1つのスレッドで動き続けます。

[Andrey Dik]

Ihor Herasko:

1.アプリには何が入っていないのですか？シンクロナイズ？)))

2）事実無根の非科学的な推論をしている。MT4では、インジケータはOnInit()とDeInit()を連続して 行うことで動作します。欠点は、すべてのインジケータが1つのスレッドで動作することです。MT5でも必要なインジケータを 適切に記述 することで解決します。とはいえ、MT5がなくなったわけではなく、とにかく1つのチャートのインジケータは1つのスレッドで動き続けます。

1.何の同期をとっているんだ！？

2.MT4では、インジケータコードの実行の一部として、まずinitが実行され、次にdeinitが実行されますが、他に何が必要ですか!!!?MT5でも同じです。

すでに何人かの方から、MT5のインジケータ実行パラダイムで行うには問題のあるタスクの具体例を挙げて欲しいとの要望がありました。事例があるのかないのか、何もないところから吸い出されたのではない、明確な事例があるのだろうか。

[Ihor Herasko]

Andrey Dik:

1.何の同期をとっているんだ!

インタースレッドについて。一方のスレッドが完了する（終了命令が出される）までは、もう一方のスレッドは起動しない。あるいは、1つのスレッドですべてが起こるなら、もっと簡単です。「古い」TFに関連するすべてのプログラムを終了させ、「新しい」TF上のプログラムだけを起動させます。

2.MT4では、インジケータコードの実行の一部として、まずinitが実行され、次にdeinitが実行されますが、他に何が必要でしょうか!MT5でも同様です。

そうですね。これはまさにMT4の場合です。しかし、MT5ではそうではありません。そして、このようなテーマがあるのです。

MT5のインジケータ実行パラダイムで行うには問題があるタスクの具体例を挙げてほしいと、すでに何人かの方から依頼されています。事例があるのかないのか、何もないところから吸い出されたのではない、明確な事例があるのだろうか。

一昨日、3つの例を 挙げたばかりです。見えないのか？

[Stanislav Korotky]

Andrey Dik:

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

OSは、TCが他のTCと干渉しないことを気にしますし、そこでRAMで何をしようが、ファイルを交換しようが、それは彼らのビジネスです。

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

トータル・コマンダーと何の関係があるのですか？システムリソースを直接操作するという意味では、低レベルのユーティリティに過ぎないのです。MQLの場合、MTプラットフォームのタスクは、アプリケーションプログラマを同期などのシステムケアから解放することです。プラットフォームは、これをより効果的に、すべての人に一挙に提供することができます。MQLプログラマーは、相場や取引戦略の分析について考えなければなりません。これがMTの目的です。

ファイルやデータのやりとりと、何か関係があるのでしょうか？仕事の論理をMQLプログラムの文脈で考えてみる。OnInit/OnDeinitイベントを本来の目的（ある状態から正しく開始し、状態を保存して正しく終了すること）に従って使用しようとするだけである。もし、この目的に適さないのであれば、すでに述べたように、何のためにあるのでしょうか？擁護者の引数から判断すると - 私たちは内部で踊り、他のコピーが前後に実行されたものを見つけることができるように、どの時間枠から、彼らが切り替えているもの？これは、MQが実現したかったこと、つまり、一方のコピーが他方のコピーについて何も知らないということとは、全く逆の効果をもたらします。

あるコピーが何も知らず、知る必要もなく、それでも副作用なく動作するためには、カーネルはすべてのコピー（シャットダウンしているコピーと起動しているコピーの両方 ）について知る必要が あり、それらのための init/deinit イベントの優雅な処理を 標準的なキューのメタファーで提供する必要があるのです。ターミナルはとにかくすべてのコピーを追跡し、イベントキューを使用しますが、何らかの理由でinit/deinitはイベントロジックを壊してしまいます。

[fxsaber]

Stanislav Korotky:

1つのコピーが何も知らず、それを理解する必要がなく、なおかつ副作用なく動作するためには、カーネルはすべてのコピー（終了するコピーと開始するコピーの両方）を認識 し、標準のキューメタファーでそれらのための優雅なinit/deinitイベントハンドリングを 提供する必要が あります。端末はすべてのコピーを記録し、イベントキューを使用しますが、なぜかinit/deinitはイベントロジックを壊してしまいます。

私もそう思います。

[Nikolai Semko]

Andrey Khatimlianskii:

メイン変数にピリオドを格納することの問題点は何でしょうか？

なぜ、異なるTFでインジケータを連続実行する間に、データの配列を転送する必要があるのでしょうか？

アンドレイ 私はグローバルターミナル変数が好きではありません。私も実験したことがありますが（だいぶ前ですが）、速度と同期の難しさにとてもがっかりしました。サポート外れにならないように、その速さを実証する例を（少し後で）書いてみることにします。もしかしたら、何かが変わっていて、私が間違っているのかもしれません。しかし、もうひとつグローバル変数の嫌なところは、グローバル変数にはそれ自身の人生があり、絶対に公開されることです。F3キーを押すことで誰でも確認でき、削除することも可能です。何本もあると、それだけで悩みは半減しますが、みんなが使い始めると、個人的には机の上がごちゃごちゃしてくる感じがします。

配列の受け渡しについて。そうですね、あまり必要ないですね。しかし、ここでは具体的な例として、私のインジケーターを 紹介します。その内部動作は選択されたTFに依存しない。なぜなら、初期化時にすべての（ほとんどすべての）TFをダウンロードし、独自の一般配列（引用符の対数配列のようなもの）を作成し、それに基づいてインデックス配列のいくつかのより大きな計算を実行するためである。TFを切り替えるときに、毎回同じ作業をするのは全く合理的ではなく、TFを切り替えるときに遅れが生じます。また、これから実装するパターン認識のアルゴリズムも頭の中にあるので、そこの初期化計算には数秒かかることもあり、一回だけやって忘れてほしいと思っています。

[Slava]

Stanislav Korotky:

1つのコピーが何も知らず、それを理解する必要がなく、なおかつ副作用なく動作するためには、カーネルはすべてのコピー（終了するコピーと開始するコピーの両方 ）について知る必要が あり、標準のキューメタファーでそれらのために優雅なinit/deinitイベント処理を 提供する必要があるのです。ターミナルはとにかくすべてのコピーを追跡し、イベントキューを使用しますが、何らかの理由でinit/deinitはイベントロジックを壊してしまいます。

そして今度は、イベントキューが1つではなく、キャラクター期間ごとにキューがあると想像してください。キャラ弁の数だけ行列ができる。

では、キューを処理する順番を提案してください。

[Stanislav Korotky]

Slawa:

そして今度は、イベントキューが1つではなく、シンボル周期ごとにキューがあると想像してください。キューの数だけシンボル期間がある。

では、キューを処理する順番を提案してください。

キューはウィンドウの属性です。インターフェイスイベントの場合、1シンボル期間あたり1キューは不正確です。では、マウスクリックはどのように処理するのでしょうか？

[Andrey Dik]

Ihor Herasko:

1.インタースレッドについて。一方のスレッドが完了する（終了命令が出される）までは、もう一方のスレッドは起動しない。あるいは、1つのスレッドですべてを行う場合は、さらに単純に、「古い」TFに接続されているすべてのプログラムの実行を終了させ、その後に「新しい」TF上のプログラムを開始させることになる。

2.そうですね。MT4でも全く同じです。しかし、MT5ではそうではありません。それがこのテーマです。

3.一昨日、一見してわかるようにグラフィカルなオブジェクトを扱う 場合、1つのインジケータがまだ存在し、クリーンアップされていない状態で、2つ目のインジケータがこれらのオブジェクトの上に描画するという美点が生まれます。そのため、「TFを切り替えると、短期的な乱れが観測されます」と、ユーザーに説明することになります。)))

DLLで作業する。Deinitするとき、DLLによって生成されたすべてのスレッドを中断する必要があります。その次のインジケーターコピーは、それらを自分用に再作成します。これで、新しいインジケーターのコピーがこれらのスレッドをすべて作成しようとすると、まだ実行中であるため拒否されることがわかりました。新しいインジケータはエラーメッセージを生成し、動作しません。ただ、TF切り替えのため。そう、この問題は解決可能なのです。

1) 先に書いたように、蓄積されたデータベースは定期的にファイルなどに保存されるべきで、ファイルを開く、書き込む、閉じる、で問題ない。ininitやdeinitではなく、このデータを更新するたびに、あるいは定期的に行う必要があります。(プログラムを書くとき、記事を書くとき、定期的に作業を保存します）。また、ファイルへの書き込みに失敗した場合の保険は不可能であり、極めて重要な場面での保険として、新しいファイルに更新情報を書き込み、書き込みに成功したら古いファイルを削除し、新しいファイルの名前を古いファイルの名前に変更する、ということを行うことがある。

2）すでに説明しました。各インジケータは、それ自身のグラフィカル・オブジェクトで動作する必要があります。もちろん、オブジェクトの存在を確認し、すでに存在している場合は、オブジェクト名に1を追加する必要があります。

3）さて、すでに解けると書かれていますね。

そして、これらはまったく問題ではありません。これは、ユニークなオブジェクトの作成、蓄積された情報の定期的な保存、終了後の後始末など、プログラムの正常な動作である。

[Ihor Herasko]

Andrey Dik:

1.これらは、あなたの希望です。しかし、あなたはデスクトップアプリケーションの動作方法を望むと言ったので、あなたが望むデスクトップアプリケーションの動作方法はうまくいかないのです。

デスクトップアプリケーションといえば？MT5がデスクトップアプリケーションでないように感じる。

2.ストーリーを作らないでください。oninit と ondeinit の順序は MT4 と MT5 で同じです。deinitで始まるプログラムというのは存在しない。

これは作り話ではありません。現在のスレッドのトピックです。ポイントは、MT5がまだDeInitしていないインジケータに対してInitを実行できることです。はい、そうです。トピックを読んでいないのでしょうか？

3）よし、例の分析をしてみよう。

1) 先に書いたようにする：蓄積されたデータベースは定期的にファイルや他のストレージに保存されるべきで、問題はない - ファイルを開いて、書いて、閉じる。ininitやdeinitではなく、このデータを更新するたびに、あるいは定期的に行う必要があります。(プログラムを書くとき、記事を書くとき、定期的に作業を保存します）。また、ファイルへの書き込みに失敗した場合の保険は不可能であり、極めて重要な場面での保険として、新しいファイルに更新情報を書き込み、書き込みに成功したら古いファイルを削除し、新しいファイルの名前を古いファイルの名前に変更する、ということを行うことがある。

同じファイルを1秒間に数回更新してみて、その感覚を共有する。

2）すでに説明しました。各インジケータは、それ自身のグラフィカル・オブジェクトで動作する必要があります。もちろん、オブジェクトの存在を確認し、すでに存在している場合は、オブジェクト名に1を追加する必要があります。

名前に1をつけることと、何か関係があるのでしょうか？同じインジケーターのグラフィックオブジェクトが、異なるコピーで同時に画面上に存在することです。技術的には何の矛盾もありません。古いコピーが削除されるまで、画面に表示される悔しさを見るユーザーには、葛藤があるだろう。

3）さて、すでに解けると書かれていますね。

これは全く問題ありません。これは、ユニークなオブジェクトの作成、蓄積された情報の定期的な保存、終了後のクリーンアップという、通常のプログラム動作です。

重大な秘密を教えましょう。DLLはターミナルのコピー1つにつき1つです。複数枚使用することはできません。