Init()およびDeInit()実行シーケンス - ページ 4 1234567891011...28 新しいコメント Sergey Chalyshev 2017.04.10 22:33 #31 fxsaber:Deinit で、すべてのデータをグローバルに書き 込む。GlobalVariableSetOnCondition により、グローバルの 1 つをセマフォとして設定します。Initでは、セマフォの状態が「data dumped」であれば、セマフォを「read all」にすることで読み出しと作業を行うことを書いています。セマフォが「理解できない」場合は、セマフォを待つだけです（ループしたSleepか OnTimerで）。セマフォが全くない場合は、初めて起動してすべてをカウントすると同時に、TFの非未来的な変化のためにセマフォを作成することを意味します。このような実装の何がそんなに複雑なのでしょうか？図書館で一回処方して終わりということ。 スリープがインジケータで動くなら、もっと簡単なんだけどな。睡眠は 指標では機能しません。 fxsaber 2017.04.10 22:38 #32 Stanislav Korotky: 共通の問題を何度も何度も小人数で解決していくと、無駄な工数が何倍にもなり（限界では無限倍;-)、端末での編集に必要な時間を超えてしまうのです。仮想の図書館があったとしても、すべての人がその存在を知り、利用する必要があることを保証するものではありません。一般に、なぜこのような "熊手 "を作り、残すのか、その理由は明らかではありません。つまり、新しいインジケーターのコピーが古いインジケーターのことを知らない場合の論理的な動作なのです。これは論理的だ!しかし、何千人もの人が、コピーでわかるように機能を追加してほしいと思っています。では、これらのユニットが、一度解答を書いて、それを使うことを妨げるものは何でしょうか？なぜ、他人を気遣うふりをするのか。本当に必要な人は、まず解決策を探します。そして、もしそうでないなら......彼らは書こうとするだろう。一元化されたコードベースは、まさにその目的に適っています。 fxsaber 2017.04.10 22:39 #33 Sergey Chalyshev: スリープがインジケーターで動けば、もっと楽なんですけどね。睡眠は 指標では機能しません。 オンタイマーからの提案です。問題はたいしたことではありません。 Stanislav Korotky 2017.04.10 22:49 #34 fxsaber:つまり、新しいコピーのインジケータが古いインジケータを知らない場合の論理的な動作であり、レイキではありません。これは論理的だ!しかし、何千人もの人が、コピーでわかるように機能を追加してほしいと思っています。では、これらのユニットが、一度解答を書いて、それを使うことを妨げるものは何でしょうか？なぜ、他人を気遣うふりをするのか。本当に必要な人は、まず解決策を探します。そして、もしそうでないなら......彼らは書こうとするでしょう。一元化されたコドベースは、まさにその役割を担っているのです。いや、そんな単純な話じゃないんです。インジケータは、別のエンティティであるチャート/図表の中にあり、それに従属するものです（1対多の複雑な関係であることは承知していますが、本質を変えるものではありません）。チャートには独自のライフサイクルがあり、そのライフサイクルには何らかの内部的なinit、deinitイベントがあり、これが指標のライフサイクルの境界となる。言い換えれば、指標はそのチャートより長生きすることはできないのです。チャートのdeinitは、すべてのインジケータのdeinitまたはdeinitのタイムアウトを待つ必要があります。このとき初めて、新しいタイムフレームのチャートのイニシエーションを開始することができ、そこから付属のインジケーターのイニシエーションを呼び出すことができるのです。熊手とは、定義上、踏めるものである。すでに踏まれている。良いソフトは原則的にレーキを認めない。 Sergey Chalyshev 2017.04.10 22:54 #35 fxsaber:つまり、新しいインジケーターのコピーが古いインジケーターのことを 知らない場合の論理的な動作なのです。これは論理的だ!しかし、何千人もの人が、コピーでわかるように機能を追加してほしいと思っています。では、これらのユニットが、一度解答を書いて、それを使うことを妨げるものは何でしょうか？なぜ、他人を気遣うふりをするのか。本当に必要な人は、まず解決策を探します。そして、もしそうでないなら......彼らは書こうとするだろう。コドベースの一元化も、まさに同じ目的です。 タイムフレームを切り替えて入力パラメータを再入力してもわからないのはどうしてですか？ Andrey Dik 2017.04.11 03:39 #36 Sergey Chalyshev: そして、Deinitはその仕事を終えて、すべてを台無しにする。独自のカスタムInitとDeinitを作れば、通常のInitとDeinitの意味がない。私もこの問題に遭遇したことがあります。(もう全部話したけど、私なりに補足しておくね。MT用のプログラムの特徴は、すべてイベントに基づいて動作することです。OnInitとOnDeinitは、イベントモデルに従って極めて論理的かつ適切に動作します。しかし、入力変数の動作には1つ奇妙なニュアンスがある。内部ターミナルのものや標準配信に含まれるものを含むすべての基本指標は、毎回、前回の起動時から呼び出されている同じ入力パラメータで起動されるのだ。とても便利です。しかし、カスタム・インディケータや、標準的なものを含むすべてのExpert Advisorやスクリプトにはそのようなものはなく、これは少し不便です（MQへの要望：入力変数に標準的なインディケータと同じ動作を追加 してください）。また、InitとDeinitに関わることですが、個人的には、プログラムのグローバル変数を扱う際に、プログラムのdeinitializationの理由を伏せたことはなく、常にプログラムの特定の考えの下にロジックを構築しています。例えば、非常に多くの場合、それはEA（理由は異なる場合があり、例えば、同じ切断はOnDeinitとその後のOnInitを引き起こす）の非初期化後にプログラムのグローバル変数を保存する必要があるので、なぜこのためにすべての上に再計算し、新しい指標のハンドルなどを作成するのですか？ だからこそ、前に書いたように、そしてfxsaberさんも、場合によってはプログラムのグローバル変数を保存する必要がある場合 - 適切なフラグを使ってターミナルのグローバル変数でそれを行うことができるのです。MQLでは残念ながら全てがスムーズではありませんが、OnInitやOndeinitの働きは論理的で理解しやすいので、勿体無いです）。 Andrey Dik 2017.04.11 03:40 #37 Sergey Chalyshev: わからないとはどういうことですか？タイムフレームを切り替えたときに、入力パラメータを再入力するのですか？ 確認しました。いいえ、TFを切り替える際に入力変数を再入力する必要はありません。 Nikolai Semko 2017.04.11 04:31 #38 Andrey Dik:しかし、OnInitとOndeinitの働きは論理的で理解しやすいので、大騒ぎする必要はないでしょう)。 タイムフレームを切り替えたときのインジケータのOnInitとOnDeinitのシーケンスのロジックを教えてください。とてもありがたいことです。そして、自分だけではないと思うのです。 Andrey Dik 2017.04.11 04:44 #39 Nikolai Semko: タイムフレームを切り替えたときのインジケータのOnInitとOnDeinitの一連の動作のロジックについて教えてください。ぜひともよろしくお願いします。そして、自分だけではないと思うのです。スラバさんは、はっきり言ってくれました。インジケーターのコピーが作成され、しばらくすると古いインジケーターがアンロードされます。プログラムのグローバル変数を保存したい場合は、OnInitを呼び出す時点で既に対処しておく必要がある（クライアント端末のグローバル変数が良い）。 そして、インジケータのバッファは、バー（ローソク足）が変更されたため、とにかく再計算されます。どうやら、このような現象が起こるようです（コピーが開始され、以前のインジケータインスタンスはターミナルによって終了されます）。もし、インディケータ開発者がグラフィカルオブジェクトを扱うことに問題があると考えるなら、インディケータの開始時に、グラフィカルオブジェクトの名前をTFの名前に結びつける必要があり、そうすれば、インディケータの新しいコピーは新しいオブジェクトを作成し、インディケータの前のコピーは古いものをクリーンアップすることができます。全く問題ありません。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム Init()およびDeInit()実行シーケンス スラワ さん 2017.04.07 15:31 どんな理屈でぐちゃぐちゃになるんだ？タイムフレームを変更すると、インジケータの新しいコピーが作成されますが、このコピーは前のコピーについて何も知りません。しばらくの間（非常に短い時間）、インジケータの両方のコピーが並行して存在します。その後、前のコピーがアンロードされます。ドキュメントを読むhttps://www.mql5.com/ru/docs/runtime/running Nikolai Semko 2017.04.11 04:50 #40 Andrey Dik:スラバさんは、はっきり言ってくれました。インジケーターのコピーが作成され、しばらくすると古いインジケーターがアンロードされます。プログラムのグローバル変数を保存したい場合は、OnInitを呼び出す時点で既に対処しておく必要がある（クライアント端末のグローバル変数が良い）。 そして、インジケータのバッファは、バー（ローソク足）が変更されたため、とにかく再計算されます。どうやら、このような現象が起こるようです（コピーが開始され、以前のインジケータインスタンスはターミナルによって終了されます）。もし、インジケーターの開発者がグラフィカルなオブジェクトを扱うことに問題があると考えるなら、インジケーターを起動するときに、グラフィカルなオブジェクトの名前をTFの名前に結びつけ、インジケーターの新しいコピーが新しいオブジェクトを作成し、インジケーターの前のコピーがそのデータをクリーンアップする必要があります。問題ありません。 そうですね、理解できますね。私は、一連の実行のロジックについて質問したのです。そんな理屈はないということです。OnDeinitが先に実行されることもあれば（一般人の理屈ではそうなるはず）、OnInitが先に実行されることもある。その答えは、「ある期間（ごく短い時間）、インジケータの両方のコピーが並行して存在 する」という発言にあると理解しています。しかし、これでは疑問が晴れない。 1234567891011...28 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
Deinit で、すべてのデータをグローバルに書き 込む。GlobalVariableSetOnCondition により、グローバルの 1 つをセマフォとして設定します。
Initでは、セマフォの状態が「data dumped」であれば、セマフォを「read all」にすることで読み出しと作業を行うことを書いています。
セマフォが「理解できない」場合は、セマフォを待つだけです（ループしたSleepか OnTimerで）。
セマフォが全くない場合は、初めて起動してすべてをカウントすると同時に、TFの非未来的な変化のためにセマフォを作成することを意味します。
このような実装の何がそんなに複雑なのでしょうか？図書館で一回処方して終わりということ。
スリープがインジケータで動くなら、もっと簡単なんだけどな。睡眠は 指標では機能しません。
共通の問題を何度も何度も小人数で解決していくと、無駄な工数が何倍にもなり（限界では無限倍;-)、端末での編集に必要な時間を超えてしまうのです。仮想の図書館があったとしても、すべての人がその存在を知り、利用する必要があることを保証するものではありません。一般に、なぜこのような "熊手 "を作り、残すのか、その理由は明らかではありません。
つまり、新しいインジケーターのコピーが古いインジケーターのことを知らない場合の論理的な動作なのです。これは論理的だ!
しかし、何千人もの人が、コピーでわかるように機能を追加してほしいと思っています。では、これらのユニットが、一度解答を書いて、それを使うことを妨げるものは何でしょうか？
なぜ、他人を気遣うふりをするのか。本当に必要な人は、まず解決策を探します。そして、もしそうでないなら......彼らは書こうとするだろう。一元化されたコードベースは、まさにその目的に適っています。
スリープがインジケーターで動けば、もっと楽なんですけどね。睡眠は 指標では機能しません。
つまり、新しいコピーのインジケータが古いインジケータを知らない場合の論理的な動作であり、レイキではありません。これは論理的だ!
しかし、何千人もの人が、コピーでわかるように機能を追加してほしいと思っています。では、これらのユニットが、一度解答を書いて、それを使うことを妨げるものは何でしょうか？
なぜ、他人を気遣うふりをするのか。本当に必要な人は、まず解決策を探します。そして、もしそうでないなら......彼らは書こうとするでしょう。一元化されたコドベースは、まさにその役割を担っているのです。
いや、そんな単純な話じゃないんです。インジケータは、別のエンティティであるチャート/図表の中にあり、それに従属するものです（1対多の複雑な関係であることは承知していますが、本質を変えるものではありません）。チャートには独自のライフサイクルがあり、そのライフサイクルには何らかの内部的なinit、deinitイベントがあり、これが指標のライフサイクルの境界となる。言い換えれば、指標はそのチャートより長生きすることはできないのです。チャートのdeinitは、すべてのインジケータのdeinitまたはdeinitのタイムアウトを待つ必要があります。このとき初めて、新しいタイムフレームのチャートのイニシエーションを開始することができ、そこから付属のインジケーターのイニシエーションを呼び出すことができるのです。
熊手とは、定義上、踏めるものである。すでに踏まれている。良いソフトは原則的にレーキを認めない。
つまり、新しいインジケーターのコピーが古いインジケーターのことを 知らない場合の論理的な動作なのです。これは論理的だ!
しかし、何千人もの人が、コピーでわかるように機能を追加してほしいと思っています。では、これらのユニットが、一度解答を書いて、それを使うことを妨げるものは何でしょうか？
なぜ、他人を気遣うふりをするのか。本当に必要な人は、まず解決策を探します。そして、もしそうでないなら......彼らは書こうとするだろう。コドベースの一元化も、まさに同じ目的です。
タイムフレームを切り替えて入力パラメータを再入力してもわからないのはどうしてですか？
そして、Deinitはその仕事を終えて、すべてを台無しにする。独自のカスタムInitとDeinitを作れば、通常のInitとDeinitの意味がない。
私もこの問題に遭遇したことがあります。(
もう全部話したけど、私なりに補足しておくね。
MT用のプログラムの特徴は、すべてイベントに基づいて動作することです。OnInitとOnDeinitは、イベントモデルに従って極めて論理的かつ適切に動作します。
しかし、入力変数の動作には1つ奇妙なニュアンスがある。内部ターミナルのものや標準配信に含まれるものを含むすべての基本指標は、毎回、前回の起動時から呼び出されている同じ入力パラメータで起動されるのだ。とても便利です。しかし、カスタム・インディケータや、標準的なものを含むすべてのExpert Advisorやスクリプトにはそのようなものはなく、これは少し不便です（MQへの要望：入力変数に標準的なインディケータと同じ動作を追加 してください）。
また、InitとDeinitに関わることですが、個人的には、プログラムのグローバル変数を扱う際に、プログラムのdeinitializationの理由を伏せたことはなく、常にプログラムの特定の考えの下にロジックを構築しています。例えば、非常に多くの場合、それはEA（理由は異なる場合があり、例えば、同じ切断はOnDeinitとその後のOnInitを引き起こす）の非初期化後にプログラムのグローバル変数を保存する必要があるので、なぜこのためにすべての上に再計算し、新しい指標のハンドルなどを作成するのですか？
だからこそ、前に書いたように、そしてfxsaberさんも、場合によってはプログラムのグローバル変数を保存する必要がある場合 - 適切なフラグを使ってターミナルのグローバル変数でそれを行うことができるのです。
MQLでは残念ながら全てがスムーズではありませんが、OnInitやOndeinitの働きは論理的で理解しやすいので、勿体無いです）。
わからないとはどういうことですか？タイムフレームを切り替えたときに、入力パラメータを再入力するのですか？
しかし、OnInitとOndeinitの働きは論理的で理解しやすいので、大騒ぎする必要はないでしょう)。
タイムフレームを切り替えたときのインジケータのOnInitとOnDeinitのシーケンスのロジックを教えてください。とてもありがたいことです。そして、自分だけではないと思うのです。
タイムフレームを切り替えたときのインジケータのOnInitとOnDeinitの一連の動作のロジックについて教えてください。ぜひともよろしくお願いします。そして、自分だけではないと思うのです。
スラバさんは、はっきり言ってくれました。
インジケーターのコピーが作成され、しばらくすると古いインジケーターがアンロードされます。
プログラムのグローバル変数を保存したい場合は、OnInitを呼び出す時点で既に対処しておく必要がある（クライアント端末のグローバル変数が良い）。
そして、インジケータのバッファは、バー（ローソク足）が変更されたため、とにかく再計算されます。どうやら、このような現象が起こるようです（コピーが開始され、以前のインジケータインスタンスはターミナルによって終了されます）。
もし、インディケータ開発者がグラフィカルオブジェクトを扱うことに問題があると考えるなら、インディケータの開始時に、グラフィカルオブジェクトの名前をTFの名前に結びつける必要があり、そうすれば、インディケータの新しいコピーは新しいオブジェクトを作成し、インディケータの前のコピーは古いものをクリーンアップすることができます。
全く問題ありません。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
Init()およびDeInit()実行シーケンス
スラワ さん 2017.04.07 15:31
どんな理屈でぐちゃぐちゃになるんだ？
タイムフレームを変更すると、インジケータの新しいコピーが作成されますが、このコピーは前のコピーについて何も知りません。しばらくの間（非常に短い時間）、インジケータの両方のコピーが並行して存在します。その後、前のコピーがアンロードされます。
ドキュメントを読むhttps://www.mql5.com/ru/docs/runtime/running
スラバさんは、はっきり言ってくれました。
インジケーターのコピーが作成され、しばらくすると古いインジケーターがアンロードされます。
プログラムのグローバル変数を保存したい場合は、OnInitを呼び出す時点で既に対処しておく必要がある（クライアント端末のグローバル変数が良い）。
そして、インジケータのバッファは、バー（ローソク足）が変更されたため、とにかく再計算されます。どうやら、このような現象が起こるようです（コピーが開始され、以前のインジケータインスタンスはターミナルによって終了されます）。
もし、インジケーターの開発者がグラフィカルなオブジェクトを扱うことに問題があると考えるなら、インジケーターを起動するときに、グラフィカルなオブジェクトの名前をTFの名前に結びつけ、インジケーターの新しいコピーが新しいオブジェクトを作成し、インジケーターの前のコピーがそのデータをクリーンアップする必要があります。
問題ありません。
そうですね、理解できますね。私は、一連の実行のロジックについて質問したのです。そんな理屈はないということです。OnDeinitが先に実行されることもあれば（一般人の理屈ではそうなるはず）、OnInitが先に実行されることもある。
その答えは、「ある期間（ごく短い時間）、インジケータの両方のコピーが並行して存在 する」という発言にあると理解しています。しかし、これでは疑問が晴れない。