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

新しいコメント
 
Slawa:

一つのシンボル内でタイムフレームの変更があった場合、初期化、非初期化の順序は原則的に予測可能である。最新のビルド1580をダウンロード - いくつかの点を修正し、インジケータが最後に削除されるようになりました。

理解できない。明確にしてください。initの後にDeinitが保証されるのか？
 
Andrey Khatimlianskii:

指標には様々な形があります。ブレーキ付きも。しかも、そのすべてが自社製でソースコード入りというわけではありません。

2、3秒は面白い。数十ミリ秒のインターフェイスを感じると、すぐに違和感が現れる。


ひねくれないようにね。インターフェースではなく、トランジェント、つまりTFの切り替えが重要なのです。白紙のチャートでは、TFの切り替えは無限大に時間がかかるのでしょうか？いや、それなら指標は関係ない。



そして何より、私の質問に対する答えがないのです。
グラフィカルなオブジェクト（名前にTF名がない）を使った単純な作業は別として、どのような状況でDeInit - Initシーケンスが重要になるのでしょうか？


ほとんどすべての場面でもちろん、MAshekタイプのおもちゃや類似のプリミティブを扱うのであれば話は別ですが。

  1. ファイルへの書き込みを行う。インジケーターの接続を解除する際には、蓄積された情報をファイルに保存することが必要です。なぜなら、ファイルを常に開いておくことは不可能だからです。クラッシュして、ファイルに記録されたすべての情報が失われる危険性があります。
  2. グラフィカルなオブジェクトを操作 する場合。1つのインジケータがまだ存在し、クリーンアップされていないのに対し、2つ目のインジケータがこれらのオブジェクトの上に描画しているというのは、実に美しいことです。そのため、「TFを切り替えると、短期的な乱れが観測されます」と、ユーザーに説明することになります。)))
  3. DLLで作業する。Deinitする場合、DLLが作成したすべてのスレッドに割り込む必要があります。その次のインジケーターコピーは、それらを自分用に再作成します。これで、新しいインジケーターのコピーがこれらのスレッドをすべて作成しようとすると、それらがまだ実行中であるため拒否されることがわかります。新しいインジケータはエラーメッセージを生成し、動作しません。ただ、TF切り替えのため。そう、この問題は解決可能なのです。

同意見です。2つ目以外の問題は、知れば解決できるものです。つまり、今はOnCalculateに全てのロジックを押し込まなければならず、一方、InitとDeInitは使ってはいけないのです。しかし、それでは何のために必要なのでしょうか？

とにかく、今はクロスプラットフォームの話をしているのではありません。MT4とMT5では、InitとDeInitのアプローチが異なることが判明しました。

 
nmaratr:


金銭的なことでなければ、おそらくこのような議論もないでしょう。

また、トレーディングアドバイザーはどちらかの指標に依存しているため、単純にTFを切り替えただけで正常に動作しなくなります。それが一番ストレスになるんです。

では、どのようにすれば財務を任せられるのでしょうか。

この問題については、MTの開発者と対立しているかもしれません。

この問題を解決するための選択肢はたくさんあります。そして、そのほとんどすべてがこのスレッドで声高に叫ばれています。

1.Expert Advisorを使用してインジケータを記述する場合、Expert Advisorは、チャートの周期変化の影響を受けないように記述する必要があります。したがって、インジケータは再初期化されません。

2.deinitでグラフィカルオブジェクトを削除したり、チャートのデザインを変更する必要がある場合は、deinitialisationの理由を 確認してください。

3.パラメータを保存する必要がある場合は、今回の声のように、deinit時に保存するのではなく、このデータを準備・変更した時に保存するようにしてください。

4）2つのガラクタの山から、常に臭いの少ない方を選ぶ。したがって、すべての指標に依存するスピードと、いくつかの指標にデータを保存することの複雑さのどちらかを選ぶなら、私はスピードを選びます。

 
Stanislav Korotky:
理解できない。説明してください。init後のdeinitは保証されるのでしょうか？

タイムフレームスイッチがダウンした場合、まず下位（新）タイムフレームでOnInitし、次に上位（旧）タイムフレームでOnDeinitする。

スイッチが上向きなら、その逆です。まず、低い（古い）タイムフレームでOnDeinitを行い、次に高い（新しい）タイムフレームでOnInitを行います。

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

 
Slawa:

最新のビルド1580をダウンロードしてください - いくつかの点を修正し、インジケータが最後に削除されるようになりました。


:(( やばい、嬉しくなってきた。Deunitが先で、Unitが後という "逆 "の設計になっているので、いくつかのプログラムではコードを書き直さなければならないかもしれませんね。
正直言って、不思議な理屈です。それは、最初の人が新しいインジケーターコピーのユニットを実行し、2番目の人が、最後の人が古いインジケーターのユニットを実行するまで、しばらくの間、新旧のインジケーターコピーが明確に同居することを意味します。その際、Deunitを通じて新しいコピーに何らかの情報を知らせることはできない。これは明らかにヤバい。単位は通常、ユニットよりもはるかに面倒なものです。なぜ、このような奇妙な順序で実行されるのでしょうか!そうすれば、この話題は何度でも蘇るだろう。しかし、もしインジケーターのプログラマーが、TFを変更しても再初期化されないような変数を作成できたとしたら、このOnInitとOnDeinitのシーケンスを処理しましょう。すでに何度か書いています（1、2）。セキュリティ上の理由から、ポインタや参照はプログラマーにとって贅沢なものではないという開発者の論理には賛成ですが、もしインジケーターのすべてのコピーに対して特殊な共有変数という仕組みを作ってしまうと、同じ仕組みを作らなければならなくなります。インジケーターは同じで、インジケーターのプロパティは「どこか」に保存されています。
 
Slawa:

タイムフレームスイッチがダウンした場合、まず最低（新）タイムフレームでOnInitし、次に最高（旧）タイムフレームでOnDeinitする。

スイッチが上向きなら、その逆です。まず、低い（古い）タイムフレームでOnDeinitを行い、次に高い（新しい）タイムフレームでOnInitを行います。

ここでは、キャッシュは低位から高位に向かって処理されることを念頭に置く必要がある

これでは余計に混乱する。

結局、作者自身が使わないインジケータなら、initとdeinitを待たずに好きなように切り替えられるということでしょうか。そして、どうなるのでしょうか。また、deinitのスイッチの1つのバリエーションに対して、いくつかのアクションを行う必要がある場合、それがスイッチの1つの方向に対して書かれていても、両方の方向に対して書かれていても、違いはないのです。しかし、「重い」インジケーターのためにブレーキを追加しているのです。

 
Alexey Viktorov:

これでは余計に混乱する。

結局のところ、インジケータが作者自身によって使用されていない場合、彼は彼が好きなように、initとdeinitを待つことなく切り替えることができますか？そして、どうなるのでしょうか？また、deinitのスイッチの1つのバリエーションに対して、いくつかのアクションを行う必要がある場合、それがスイッチの1つの方向に対して書かれていても、両方の方向に対して書かれていても、違いはないのです。しかし、「重い」インジケーターのためにブレーキを追加したのです。

ブレーキはどこに追加されたのですか？何を追加したかと比較すると？

あなたの発言は、誰もが再現できるように、コードでサポートしてください。

もう一度言います。シンボル周期の変更時に別のインジケータのコピーが作成されるため、新しいシンボル周期でのOnInitと古いシンボル周期でのOnDeinitの順序は未定義です。

 
Slawa:

ブレーキはどこに追加されたのですか？何を追加したかに比べて？

誰もが再現できるように、コードで裏付けを取るのが親切です。

もう一度言います。シンボル期間を変更するとインジケータの 別コピーが作成されるため、新しいシンボル期間でOnInit、古いシンボル期間でOnDeinitを実行する順序は未定義です。

このメッセージの中で

スラワ：

タイムフレームの切り替えがうまくいかなくなったら、まず一番若い（新しい）タイムフレームでOnInitし、次に一番古い（古い）タイムフレームでOnDeinitします。

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

キャッシュは低次の時間枠から高次の時間枠へと処理されることを念頭に置いておく必要があります。

ありのままを伝えたのか、それとも新築準備の時のように？

もしそうなら、私の勘違いなので、撤回します。

 
Alexey Viktorov:

このメッセージの中に

新築を準備する際に、そのままというか、やったようにと言ったのでしょうか？

そのままなら、誤解しているので取り消す。

これは、ビルド1580で行われます。

それ以前は、タイムフレーム変更時の非初期化の方が早い場合がほとんどでした。しかし、タイムフレームスイッチがダウンした場合のみ、初期化解除が3ではなく、コード1で行われたため、本来は

 
Slawa:

これは、ビルド1580で行われます。

それ以前は、タイムフレーム変更時の非初期化は、ほとんど以前から行われていました。しかし、タイムフレームスイッチがダウンした場合のみ、本来であればコード3ではなくコード1で初期化が行われました


では、インジケーターのIniteで、これらの非初期化のコードをどのように処理すればいいのでしょうか。インジケーターで待機することができないため、スリープが 機能しない。
1234567891011121314...28
新しいコメント