Init()およびDeInit()実行シーケンス - ページ 19 1...121314151617181920212223242526...28 新しいコメント Nikolai Semko 2017.04.14 12:52 #181 Slawa:No solutionは「解き方がわからない」という意味で、「解かない」という意味ではありません。また、ユーザーイベントについては、全く問題ありません。 ふぅ...。怖いよ......。) Stanislav Korotky 2017.04.14 13:23 #182 fxsaber:サービスや、1つのチャート上で複数のEAを実行する機能では、議論されている問題を完全にカバーできないのでは? まあ、問題は残りますが。新しいタイプのMQLプログラムができたからと言って、他のタイプのMQLプログラムの問題が解決するわけではありません。良いソフトウェアは、ユーザーにミスをさせません。ヘルプで動作の不確かさについて句を書くのは、もちろん簡単です。溺れる人を救うのは、溺れる人次第。 fxsaber 2017.04.14 13:26 #183 Stanislav Korotky: 溺れる人を救うのは、溺れる人次第。 もちろん、命綱を投げても溺れる人の救いに貢献しない岩を嘆き続けることもできる。 Alexey Viktorov 2017.04.14 13:53 #184 elibrarius: TFを変更する際のdeinitとinitのキューに関する建設的な議論に無関係であるとして、投稿125以降のすべてを削除することを提案します。 スレッドごと削除したほうがいいのでは?そして、嫌な夢のように忘れてしまうのです。 Alexey Viktorov 2017.04.14 13:57 #185 Dmitry Fedoseev:ある指標では、最初にイニシャル、次にデイニットとなっています。しかし、タイムフレームが切り替わると、2つ目のインジケータ・インスタンスが作成され、そのinitは前の(未チャートの)インスタンスのdeinitより早く実行されることがあります。最も分かりやすい例として、タイムフレームを切り替えたときにユーザーパラメータを保存 する場合、deinitでパラメータを保存し、initで読み込むことになります。新しいインスタンスのinitが前のインスタンスのdeinitの前にトリガーされた場合、パラメータは保存されません。実用的には、削除されたインスタンスのdeinitが新しいインスタンスのinitより先にトリガーされることがほとんどですが、時間軸が非常に早く切り替わったり、データがロードされたりすると、失敗が発生します。ディミトリ、車を運転するとき、すでに到着しているのにバックミラーを見る必要があるのでしょうか?それとも、定期的に必要なパラメータをインジケータに保存する必要があるのでしょうか?まるでバックミラーを見ているような感覚です。 Stanislav Korotky 2017.04.14 14:03 #186 fxsaber: もちろん、溺れた人に救命胴衣を投げても、石が救命に貢献しないことが続くと文句を言ってもいい。熊手は残る。それが最大のポイントです。(この例えの場合、ボート場でオンデマンドでラップが配られ、ランダムに不意に人が溺死する)。古いチップが大丈夫でなければ、新しいチップも大丈夫でしょう。アプローチは変わりません。全体として、私はすべてを、合理的かつ論理的に述べてきたと思います。水槽の中にいる人がいたら、どうしようもない。 fxsaber 2017.04.14 14:15 #187 Stanislav Korotky:旧来の機能が万全でなければ、新しい機能もそうなるでしょう。アプローチは変わりません。 ここで問題なのは、彼らができないのか、それともしないのか、ということだ。できないようです。 TheXpert 2017.04.14 14:47 #188 Slawa:つまり、チャートの シンボル周期を変更する際のインジケータのOnInitとOnDeinitの実行順序は、誰も気にする必要はないはずだonInit でタイマーを開始し、onDeinit でタイマーを削除します。間違った行列の結果、誰も何がなんだかわからない。開発者があからさまに無視する不快なバグ fxsaber 2017.04.14 14:52 #189 Комбинатор:Initはタイマーを開始し、deinitはタイマーを削除します。キューを間違えた結果、何が起こっているのかわからなくなる。開発者があからさまに無視する厄介なバグ キューは曖昧なものではありません。 TheXpert 2017.04.14 15:04 #190 fxsaber: 命令は一義的なものです。fを変更したとき。もし、インジケータに古いTFからのゴミがバッファに残っていたら、もしかしたらタイマも影響を受けるかもしれません。 1...121314151617181920212223242526...28 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
No solutionは「解き方がわからない」という意味で、「解かない」という意味ではありません。
また、ユーザーイベントについては、全く問題ありません。
サービスや、1つのチャート上で複数のEAを実行する機能では、議論されている問題を完全にカバーできないのでは?
溺れる人を救うのは、溺れる人次第。
TFを変更する際のdeinitとinitのキューに関する建設的な議論に無関係であるとして、投稿125以降のすべてを削除することを提案します。
ある指標では、最初にイニシャル、次にデイニットとなっています。しかし、タイムフレームが切り替わると、2つ目のインジケータ・インスタンスが作成され、そのinitは前の(未チャートの)インスタンスのdeinitより早く実行されることがあります。
最も分かりやすい例として、タイムフレームを切り替えたときにユーザーパラメータを保存 する場合、deinitでパラメータを保存し、initで読み込むことになります。新しいインスタンスのinitが前のインスタンスのdeinitの前にトリガーされた場合、パラメータは保存されません。
実用的には、削除されたインスタンスのdeinitが新しいインスタンスのinitより先にトリガーされることがほとんどですが、時間軸が非常に早く切り替わったり、データがロードされたりすると、失敗が発生します。
ディミトリ、車を運転するとき、すでに到着しているのにバックミラーを見る必要があるのでしょうか?それとも、定期的に必要なパラメータをインジケータに保存する必要があるのでしょうか?まるでバックミラーを見ているような感覚です。
もちろん、溺れた人に救命胴衣を投げても、石が救命に貢献しないことが続くと文句を言ってもいい。
熊手は残る。それが最大のポイントです。(この例えの場合、ボート場でオンデマンドでラップが配られ、ランダムに不意に人が溺死する)。
古いチップが大丈夫でなければ、新しいチップも大丈夫でしょう。アプローチは変わりません。
全体として、私はすべてを、合理的かつ論理的に述べてきたと思います。水槽の中にいる人がいたら、どうしようもない。
旧来の機能が万全でなければ、新しい機能もそうなるでしょう。アプローチは変わりません。
つまり、チャートの シンボル周期を変更する際のインジケータのOnInitとOnDeinitの実行順序は、誰も気にする必要はないはずだ
onInit でタイマーを開始し、onDeinit でタイマーを削除します。間違った行列の結果、誰も何がなんだかわからない。
開発者があからさまに無視する不快なバグ
Initはタイマーを開始し、deinitはタイマーを削除します。キューを間違えた結果、何が起こっているのかわからなくなる。
開発者があからさまに無視する厄介なバグ
命令は一義的なものです。
fを変更したとき。
もし、インジケータに古いTFからのゴミがバッファに残っていたら、もしかしたらタイマも影響を受けるかもしれません。