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

新しいコメント
 
Slawa:

No solutionは「解き方がわからない」という意味で、「解かない」という意味ではありません。

また、ユーザーイベントについては、全く問題ありません。

ふぅ...。怖いよ......。）
 
fxsaber:

サービスや、1つのチャート上で複数のEAを実行する機能では、議論されている問題を完全にカバーできないのでは？

まあ、問題は残りますが。新しいタイプのMQLプログラムができたからと言って、他のタイプのMQLプログラムの問題が解決するわけではありません。良いソフトウェアは、ユーザーにミスをさせません。ヘルプで動作の不確かさについて句を書くのは、もちろん簡単です。溺れる人を救うのは、溺れる人次第。
 
Stanislav Korotky:
溺れる人を救うのは、溺れる人次第。
もちろん、命綱を投げても溺れる人の救いに貢献しない岩を嘆き続けることもできる。
 
elibrarius:
TFを変更する際のdeinitとinitのキューに関する建設的な議論に無関係であるとして、投稿125以降のすべてを削除することを提案します。
スレッドごと削除したほうがいいのでは？そして、嫌な夢のように忘れてしまうのです。
 
Dmitry Fedoseev:

ある指標では、最初にイニシャル、次にデイニットとなっています。しかし、タイムフレームが切り替わると、2つ目のインジケータ・インスタンスが作成され、そのinitは前の（未チャートの）インスタンスのdeinitより早く実行されることがあります。

最も分かりやすい例として、タイムフレームを切り替えたときにユーザーパラメータを保存 する場合、deinitでパラメータを保存し、initで読み込むことになります。新しいインスタンスのinitが前のインスタンスのdeinitの前にトリガーされた場合、パラメータは保存されません。

実用的には、削除されたインスタンスのdeinitが新しいインスタンスのinitより先にトリガーされることがほとんどですが、時間軸が非常に早く切り替わったり、データがロードされたりすると、失敗が発生します。

ディミトリ、車を運転するとき、すでに到着しているのにバックミラーを見る必要があるのでしょうか？それとも、定期的に必要なパラメータをインジケータに保存する必要があるのでしょうか？まるでバックミラーを見ているような感覚です。

 
fxsaber:
もちろん、溺れた人に救命胴衣を投げても、石が救命に貢献しないことが続くと文句を言ってもいい。

熊手は残る。それが最大のポイントです。(この例えの場合、ボート場でオンデマンドでラップが配られ、ランダムに不意に人が溺死する）。

古いチップが大丈夫でなければ、新しいチップも大丈夫でしょう。アプローチは変わりません。

全体として、私はすべてを、合理的かつ論理的に述べてきたと思います。水槽の中にいる人がいたら、どうしようもない。

 
Stanislav Korotky:

旧来の機能が万全でなければ、新しい機能もそうなるでしょう。アプローチは変わりません。

ここで問題なのは、彼らができないのか、それともしないのか、ということだ。できないようです。
 
Slawa:

つまり、チャートの シンボル周期を変更する際のインジケータのOnInitとOnDeinitの実行順序は、誰も気にする必要はないはずだ

onInit でタイマーを開始し、onDeinit でタイマーを削除します。間違った行列の結果、誰も何がなんだかわからない。

開発者があからさまに無視する不快なバグ

 
Комбинатор:

Initはタイマーを開始し、deinitはタイマーを削除します。キューを間違えた結果、何が起こっているのかわからなくなる。

開発者があからさまに無視する厄介なバグ

キューは曖昧なものではありません。
 
fxsaber:
命令は一義的なものです。

fを変更したとき。

もし、インジケータに古いTFからのゴミがバッファに残っていたら、もしかしたらタイマも影響を受けるかもしれません。

1...121314151617181920212223242526...28
新しいコメント