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

 
Aleksei Radchenko:


端末をバージョン1065にアップデートしてみてください。以前のバージョンでは、タイムフレームを変更しただけで再初期化エラーが発生しました。役に立つかもしれません :)

https://www.mql5.com/ru/forum/187690


ターミナル5.00 b1571を使用しています。
 
変数の値をグローバルなどに保存しておけば、再翻訳後にその変数を読み込んで復元することができます。
 
Andrey Dik:
変数の値は、例えばグローバルなど、どこかに保存しておくことができます。 翻訳した後、変数を読んだり復元したりすることができます。


そして、Deinitはその仕事を終えて、すべてを台無しにする。独自のInitとDeinitを作成する場合は、通常のInitとDeinitの意味がありません。

私もこの問題に遭遇したことがあります。(

 
Sergey Chalyshev:


そして、デイニットはその仕事を終えて、すべてを台無しにしてしまうのです。独自のカスタムInitとDeinitを作れば、通常のInitとDeinitの意味がない。

私もこの問題に遭遇したことがあります。(


全く同感です(通常のInitとDeinitでは意味がない)。
 
Vasiliy Pushkaryov:


グラフィカルなオブジェクトには、名前のプレフィックスの一部としてTFピリオドを割り当ててみてはいかがでしょうか。

というようなものを適用します。


返信ありがとうございました

ああ、そういうことだったんだ、でも部分的な解決策なんだ。

リソースやファイルを通して変数と同じことができますが、これは別途追加リソースが必要で、MT5を修正することで回避できたはずです

余分なサイドファンクションやチェックなどでコードを乱雑にする。(WITHOUT......)

 

私は、TFを変更するときは、まず古いTFでdeinitし、新しいTFでInitするものだと思っていました(無駄なことですが...)。これは論理的な流れであり、Expert Advisorやインジケータを開発する際にもこの論理を頼りにしていました。そして今度は、一連の流れにイベントが割り込んでくるという、実にナンセンスな展開に......。
時々、チャートやグラフィックオブジェクトに異常があることに気づき、すべてが正しく表示されていることを確認するために、何度もTFを切り替える必要がありました。


今はdeinitesの何かが変わるとinitesも元に戻るというコードで...順番が逆になっていることが判明!!!ひどい論理ですね。これは誰が考えたのでしょうか?

まず、私のdeinitでは、以前の状態(ボタンが押された/離された)をグローバル変数に保存し、initsで保存された値に従ってボタンを設定するようになっています。そして、いつも正しくリセットされないのは、ボタンです。これは最初に思い出したことで、もしかしたら他にも何かあるかもしれない...。は明日も掘りまくる予定です。


開発者の皆さん、お疲れ様でした...。

 

Deinit で、すべてのデータをグローバルに書き 込む。GlobalVariableSetOnCondition により、グローバルの 1 つをセマフォとして設定します。

Initでは、セマフォが「data dumped」状態であれば、「read all」状態にセマフォを設定することで読み込んで作業することを書いています。

セマフォが「理解できない」場合は、セマフォを待つだけです(ループしたSleepかOnTimerで)。


セマフォが全くない場合は、初めて起動してすべてをカウントすると同時に、TFの非未来的な変化のためにセマフォを作成することを意味します。


このような実装の何がそんなに複雑なのでしょうか?図書館で一回処方して終わりということ。

 
fxsaber:

Deinit で、すべてのデータをグローバルに書き 込む。GlobalVariableSetOnCondition により、グローバルの 1 つをセマフォとして設定します。

Initでは、セマフォが「data dumped」状態であれば、「read all」状態にセマフォを設定することで読み込んで作業することを書いています。

セマフォが「読めない」場合は、セマフォが戻るのを待つだけです(ループのSleepかOnTimerで)。


このような実装の何がそんなに複雑なのでしょうか?図書館で一度書いて終わりということ。

そんな問題があるなんて知りませんでした。deinit-initの順番を期待していたのですが、その逆はありませんでした。問題を知れば、解決できるかもしれない。しかし、それは端末のロジックレベルで解決すべきことであって、プログラムごとに松葉杖をつく必要はないように思うのですが......。
 
elibrarius:
そんな問題があるなんて、まったく知りませんでした。私はdeinit-initの順序を期待していたのですが、その逆はありませんでした。問題を知れば、解決できる。しかし、それは末端の論理レベルで解決すべきことであって、今、すべてのプログラムに挿入されるべき松葉杖ではないような気がするのですが......。
松葉づえではなく、シンプルな解決策なのです。問題は、開発者とユーザー、どちらがそれを実装するかです。どちらの場合も、時間をかけて一度は書いてみるべきです。ユーザーができることであれば、それを書き、それ以上わざわざ問題を論じることはない。私自身、スレッドを読んだだけで、すぐに解決策が浮かびました。何をじっくりと見るのか?長い時間をかけて何かを要求することもできますし、自分で素早く書くこともできます。
 
fxsaber:
これは松葉杖ではなく、シンプルな解決策なのです。問題は、開発者とユーザーのどちらがそれを実装するかということだ。どちらの場合も、時間をかけて一度書く必要があります。ユーザーができることであれば、それを書き、それ以上わざわざ問題を論じることはない。私自身、スレッドを読んだだけで、すぐに解決策が浮かびました。何をじっくりと見るのか?長い時間をかけて何かを要求することもできますし、自分で素早く書くこともできます。
共通の問題を何度も何度も解決する小人数を掛け合わせると、無駄な工数は何倍にもなり(限界では無限倍;-)、端末での編集に必要な時間を超えてしまいます。仮想の図書館があったとしても、すべての人がその存在を知り、利用する必要があることを保証するものではありません。一般に、なぜこのような "熊手 "を作り、残すのか、その理由は明らかではありません。