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

 
Ihor Herasko:


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

したがって、TF切り替え時のブレーキについての議論は怪しさ満点である。それに、まだ作っていないTFに切り替えると、むしろタイムラグが感じられる。そして、端末のブレーキに泣く人はいない。

指標は異なります。また、遅いものもあります。しかも、そのすべてが自社製でソースコード入りというわけではありません。

数秒の間に面白がっているのです。インターフェースに数十ミリ秒を感じ、一気に違和感を覚えます。

そして、最も重要なことは、私の質問に対する答えがないことです:
グラフィカル・オブジェクト(タイトルにTF名がない)を使った単純作業以外のどんな状況で、DeInit - Initシーケンスが重要なの でしょうか?

 
Andrey Khatimlianskii:

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

2、3秒は面白い。インターフェイスに数十ミリ秒を感じると、一気に違和感がありますね。

そして何より、私の質問に対する答えがないのです。
グラフィカル・オブジェクト(名前にTF名を含まない)を使った単純な作業以外に、どのような場面でDeInit - Initシーケンスが重要になるのでしょうか?


普段はグローバル変数を使わないのですが、たまにはそういうこともあります。

グローバル変数を扱うと、混乱が生じる。チャートからインジケータを削除する場合、後始末としてグローバル変数を削除 する必要があります。インジケーターのどの場所でグローバル変数を削除するのでしょうか?おそらく、Deiniteで削除されるはずで、他に場所はない。だから、タイムフレームを変えて新しい変数を作ると、Deiniteがやってきて全部消してしまうんです。Global Variablesはインジケータで使用できないことがわかりました。

 
Sergey Chalyshev:


普段はグローバル変数を使わないのですが、たまにありますね。

グローバル変数を扱うと、途切れ途切れになってしまう。チャートからインジケータを削除するときは、後片付けをして、グローバル変数を削除 する必要があります。インジケーターのどの場所でグローバル変数を削除するのでしょうか?おそらく、Deiniteで削除されるはずで、他に場所はない。だから、タイムフレームを変えて新しい変数を作ると、Deiniteがやってきて全部消してしまうんです。Global Variablesはインジケータで使用できないことが判明しました。

セルジ、漠然としたものでない実例をお持ちですか?そのような例も考えられますが、実際に問題に直面したことはありません。

注:グローバル変数には、TFに応じた名前を付けることもできます。

 
Andrey Khatimlianskii:

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

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

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

3ページ目では、実際の例を挙げました。
まず、私のdeinitでは、以前の状態(ボタンが押された/離された)をグローバル変数に保存し、initsで保存された値に従ってボタンを設定するようになっています。そして、いつも正しくリセットされないのは、ボタンです。これは最初に思い出したことで、他にも何か見つかるかもしれない...。
 
elibrarius:
のページで、実際の例を挙げました。

ini/deinit時ではなく、関連する変数が変更されるたびにターミナルヘッドに記憶させる。
 
Andrey Dik:

は、ini/deinit時ではなく、対応する変数が変更されるたびにメインターミナルに記憶されます。

覚えておくよ)
また、現在の実装では、Deinitでは何もできず、その後に使用しなければならない(グローバル変数でもファイルへの書き込みでもない)ことを忘れないでください...。

フィンチは、このような破綻したシーケンスを持つ、本質的に役に立たない存在になってしまったのです。

私は覚えていますが(偶然このスレッドに辿り着いたので良かった)、他のプログラマーは(ここを見ないでしょうが)自然な論理的帰結を使って、うまくいくことを期待してDeinitを使って、新しいTFでinitが実行されることでしょう。

 
elibrarius:

覚えておくよ)
また、現在のターミナルの実装では、Deinit時に後で使用するようなことはできません(グローバル変数にも、ファイルにも)...。

屁の突っ張りにもならない。

ただ、他のロジックもあることを理解してください。特にMT開発者のロジック。この論理に従えば、すべてが論理的に見える。したがって、結論としては、このロジックに合わせ、おそらくあなたよりも経験豊富な人々の考えを変えようとはしないことです。無駄です...。一つの指標のために、確立された論理を変えることには誰も賛成しないでしょう。
 
まあ、この問題は私が初めてではないので、1つの指標のためというわけでもないのですが。自分はもうやり尽くしたが、他の人もこの熊手を踏んでいるかもしれない。誰も踏まないように熊手を外すだけの方がいいのでは?
 
Alexey Viktorov:
ただ、他のロジックもあることを理解してください。特にMT開発者のロジック。この、他の論理によると、すべてが非常に論理的に見えます。したがって、結論としては、このロジックに合わせ、おそらくあなたよりも経験豊富な人々の考えを変えようとはしないことです。無駄です...。一つの指標のために、確立された論理を変えることには誰も賛成しないでしょう。


金融の話でなければ、おそらくこのような議論はなかったでしょう。

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

では、どうして彼に経済的なことを任せられるのでしょうか?

この点については、MTの開発者と意見が対立しているかもしれません。
 
Andrey Khatimlianskii:

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

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

皆さん、いろいろと混同されているようですね。重要なソフトウェアである端末の要件として、少なくとも2つは合意しておこう。

- 同じロジックで厳密に動作し、予測可能でなければならない(マルチスレッドであっても)。

- 素早く動作する必要があります。

(インジケーターのコピーが他のコピーについて知っているかどうかは重要ではありませんが、端末に保存用に割り当てられたグローバルデータが一貫して いることが重要です。これは、各インジケーター開発者ではなく、端末の関心事です)

さらに、それをどのように実現するかという問題があります。現在は要件2を考慮して実装しています。要件2に影響を与えず、要件1を考慮して実施することを提案します。

チャートのinit/deinitとインジケータのinit/deinitのイベントは別物であることに注意すれば、顕著な速度低下はありません。チャートはすぐにメインの新しいチャートを表示しますが、レガシー指標については、OnInitイベントは前のOnDeinitの処理後にキューに入れられます。イベントはとにかく端末に キューイングされる。

MQが望むなら、クラスとシーケンスの彼の条件NDAのチャートで私を送ることができ、私はそれらを修正します;-)。