Init()およびDeInit()実行シーケンス - ページ 11 1...456789101112131415161718...28 新しいコメント Yuriy Zaytsev 2017.04.13 04:41 #101 Alexey Viktorov: そんなつまらないことで無駄な言い争いをしている時間がもったいないと思いませんか?実は、この特殊性を意識するだけでも、もっと大切なことなのです。 Ihor Herasko 2017.04.13 06:47 #102 Andrey Dik:コピーに必要なデータは常に最新にしておくこと、イニシエーションの時だけでなく、常に最新にしておくこと、とはっきり書きました。このデータはどこで最新にすべきなのか?一例をお願いします。ファイル以上のものはないと思います。だから、ファイルだけでは大問題なんです。それとも、1秒ごとにファイルを更新することが優れた習慣だとお考えですか?それ以外のケースはすべて、気難しさによる作為的なものです。では、「ブルースクリーンでの一時的な乱れ」も、インジケーターを書いている方の責任なのでしょうか?これはまさに、まだ誰もどうすればいいのか言っていない例です。そして、それを回避する方法はありません。同じインジケータを同時に実行することに問題がある場合、TFへのリンクで毎回ユニークなオブジェクトを作成し、すでにオブジェクトがある場合は名前に1を追加してください。現在の端末のインジケーターの動作方法によって、問題が解決されないケースは一つも挙げられていない。インジケーターの取り扱いが不適切なために発生する問題です。すでにいくつかの例を挙げました。しかし、あなたはそれを簡単に否定してしまう、つまり問題に目をつぶってしまうのです。一般に、プログラムが3種類あることには理由があることを理解していない人が多いようです(4種類目は近々登場します)。 そう、理由があるのです。それは、中途半端に立ち止まってしまうという、人間の単純な弱点が原因です。結局のところ、プラットフォームには1種類のプログラムしかないはずです。それ以上でも以下でもない。第4のタイプの出現は、自堕落の深化である。 Andrey Dik 2017.04.13 08:07 #103 Ihor Herasko:そう、理由があるのです。人間の 初歩的な弱点である「途中で やめる」ことが原因です。1つのプラットフォームには1種類のプログラムでなければならない。それ以上でも以下でもない。第4のタイプの出現は、自堕落の深化である。そういう開発者に対する姿勢で、開発者が問題を解決してくれることを期待するのはおかしい。そして、プラットフォームのあらゆる改善と簡素化を熱烈に支持する私でさえ問題ないと思えば、途中でやめるのが好きな人たちもきっと問題ないと思うのです。 Nikolai Semko 2017.04.13 08:13 #104 Alexey Viktorov: そんなつまらないことで無駄な言い争いをして時間を浪費するのは、もったいないと思いませんか? その通りだ!しかし、あなたは何も間違っていない。 Ihor Herasko 2017.04.13 08:20 #105 Andrey Dik:そういう開発者に対する姿勢で、「開発者が問題を解決してくれることを期待する」というのは、あなたからすると不思議な話です。 プラットフォーム開発者に対しては、普通の態度です ))人間の弱さは私たち共通の問題であり、その代表者個人の問題ではありません。プログラムの種類の話から、本当に話がそれてしまいましたが。それ用のスレッドを別に用意した方がいい。しかし、実用化の気配すらない純粋な学術的なものになるため、あまり意味がないと思います。私が言っている意味は、プログラム実行の 通常のロジックのことです。このようなロジックはMT4にあったもので、いい意味でMT5に引き継がなければならない。実は、これはMT4のデメリットではありません。この場合、MT5に対する優位性である。ですから、MT5を開発してMT4のことを早く忘れたいのであれば、MT4の良いところを取り入れてはいかがでしょうか。まあ、欠点は直して、せめて長所は改善しないとね。しかし、新たな欠点を持ち込むのは......。 Georgij Komarov 2017.04.13 08:29 #106 Nikolai Semko: それでいいのか!? この理由コード(REASON_CHARTCHANGE)をフルに使って、実験してみました。すべての変数が再び元の状態に設定され、新しいTFのOnInitの後にOnDeinitが実行できるのであれば、何の役に立つのでしょうか?非初期化の理由 UninitializeReason()によって返されるExpert Advisorの 初期化理由コード。以下のいずれかの値を持つことができる。.........インジケータは 現在、コード1(REASON_REMOVE)とコード2(REASON_RECOMPILE)のみを受け付けます。 Nikolai Semko 2017.04.13 08:35 #107 Georgij Komarov: 非初期化の理由 UninitializeReason()によって返されるExpert Advisorの 初期化理由コード。以下のいずれかの値を持つことができる。.........インジケータは 現在、コード1(REASON_REMOVE)とコード2(REASON_RECOMPILE)のみを受け付けます。 本当ですか? Slava 2017.04.13 09:08 #108 Georgij Komarov: 非初期化の理由 UninitializeReason()によって返されるExpert Advisorの 初期化理由コード。以下のいずれかの値を持つことができる。.........インジケータは 現在、コード1(REASON_REMOVE)とコード2(REASON_RECOMPILE)のみを受け付けます。これは時代遅れの情報です。多くの要望を受け、他の理由も指標に送るようになりましたディスカッションもたくさんありました。インジケーターのコピー違いについて、誰も覚えていないのが不思議なくらいです。 Andrey Dik 2017.04.13 09:19 #109 Ihor Herasko: プラットフォーム開発者に対しては、普通の態度です ))人間の弱さは私たち共通の問題であり、その代表者個人の問題ではありません。さすがに番組の種類の話からは脱線してしまいましたが。このために別のブランチを立ち上げるべきでした。しかし、実用化の気配すらない純粋な学術的なものになるため、あまり意味があるとは思えません。私が言っている意味は、 プログラム実行の 通常のロジックのことです。このようなロジックはMT4にあったもので、いい意味でMT5に引き継がなければならない。実は、これはMT4のデメリットではありません。この場合、MT5に対する優位性である。ですから、MT5を開発してMT4のことを早く忘れたいのであれば、MT4の良いところを取り入れてはいかがでしょうか。まあ、欠点は直して、せめて長所は改善しないとね。しかし、新たな欠点を持ち込むのは......。それだ、俺たちは文句を言ってるんだ...。 まさに、通常のデスクトップアプリケーションにはないものを求めているのです。もし開発者が、すでに「箱から出して」あるこれらの機能をすべて行わなければ、MQLプログラムの書き手は、セキュリティの問題であれ実行速度であれ、デスクトップ開発のあらゆる魅力に常に直面することになります。 Andrey Khatimlianskii 2017.04.13 11:13 #110 Nikolai Semko: 複雑なことではなく、非常に疑問のある質問です。 この製品で 実装したことを、シンプルな腕時計の例で本当に再現してみてください。リストホイールではマウスでピリオドを変更し、TFを変更すると、変更内容が保存されるはずです。そして、何も複雑なことはないことがおわかりいただけると思います。そして、配列を渡す必要がある場合。そして、その「シンプルさ」を実感してください。おそらく、まだ実装していなければ、私自身もそう思うはずです。メイン変数にピリオドを格納することの問題点は何でしょうか?なぜ、異なるTFでインジケータを連続実行する間に、データの配列を転送する必要があるのでしょうか? 1...456789101112131415161718...28 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
そんなつまらないことで無駄な言い争いをしている時間がもったいないと思いませんか?
実は、この特殊性を意識するだけでも、もっと大切なことなのです。
コピーに必要なデータは常に最新にしておくこと、イニシエーションの時だけでなく、常に最新にしておくこと、とはっきり書きました。
このデータはどこで最新にすべきなのか?一例をお願いします。ファイル以上のものはないと思います。だから、ファイルだけでは大問題なんです。それとも、1秒ごとにファイルを更新することが優れた習慣だとお考えですか?
それ以外のケースはすべて、気難しさによる作為的なものです。
では、「ブルースクリーンでの一時的な乱れ」も、インジケーターを書いている方の責任なのでしょうか?これはまさに、まだ誰もどうすればいいのか言っていない例です。そして、それを回避する方法はありません。
同じインジケータを同時に実行することに問題がある場合、TFへのリンクで毎回ユニークなオブジェクトを作成し、すでにオブジェクトがある場合は名前に1を追加してください。
現在の端末のインジケーターの動作方法によって、問題が解決されないケースは一つも挙げられていない。インジケーターの取り扱いが不適切なために発生する問題です。
すでにいくつかの例を挙げました。しかし、あなたはそれを簡単に否定してしまう、つまり問題に目をつぶってしまうのです。
一般に、プログラムが3種類あることには理由があることを理解していない人が多いようです(4種類目は近々登場します)。
そう、理由があるのです。人間の 初歩的な弱点である「途中で やめる」ことが原因です。1つのプラットフォームには1種類のプログラムでなければならない。それ以上でも以下でもない。第4のタイプの出現は、自堕落の深化である。そういう開発者に対する姿勢で、開発者が問題を解決してくれることを期待するのはおかしい。
そして、プラットフォームのあらゆる改善と簡素化を熱烈に支持する私でさえ問題ないと思えば、途中でやめるのが好きな人たちもきっと問題ないと思うのです。
そんなつまらないことで無駄な言い争いをして時間を浪費するのは、もったいないと思いませんか?
そういう開発者に対する姿勢で、「開発者が問題を解決してくれることを期待する」というのは、あなたからすると不思議な話です。
プラットフォーム開発者に対しては、普通の態度です ))人間の弱さは私たち共通の問題であり、その代表者個人の問題ではありません。
プログラムの種類の話から、本当に話がそれてしまいましたが。それ用のスレッドを別に用意した方がいい。しかし、実用化の気配すらない純粋な学術的なものになるため、あまり意味がないと思います。
私が言っている意味は、プログラム実行の 通常のロジックのことです。このようなロジックはMT4にあったもので、いい意味でMT5に引き継がなければならない。実は、これはMT4のデメリットではありません。この場合、MT5に対する優位性である。ですから、MT5を開発してMT4のことを早く忘れたいのであれば、MT4の良いところを取り入れてはいかがでしょうか。まあ、欠点は直して、せめて長所は改善しないとね。しかし、新たな欠点を持ち込むのは......。
それでいいのか!?
この理由コード(REASON_CHARTCHANGE)をフルに使って、実験してみました。すべての変数が再び元の状態に設定され、新しいTFのOnInitの後にOnDeinitが実行できるのであれば、何の役に立つのでしょうか?
非初期化の理由
UninitializeReason()によって返されるExpert Advisorの 初期化理由コード。以下のいずれかの値を持つことができる。
.........
インジケータは 現在、コード1(REASON_REMOVE)とコード2(REASON_RECOMPILE)のみを受け付けます。
非初期化の理由
UninitializeReason()によって返されるExpert Advisorの 初期化理由コード。以下のいずれかの値を持つことができる。
.........
インジケータは 現在、コード1(REASON_REMOVE)とコード2(REASON_RECOMPILE)のみを受け付けます。
非初期化の理由
UninitializeReason()によって返されるExpert Advisorの 初期化理由コード。以下のいずれかの値を持つことができる。
.........
インジケータは 現在、コード1(REASON_REMOVE)とコード2(REASON_RECOMPILE)のみを受け付けます。
これは時代遅れの情報です。多くの要望を受け、他の理由も指標に送るようになりました
ディスカッションもたくさんありました。インジケーターのコピー違いについて、誰も覚えていないのが不思議なくらいです。
プラットフォーム開発者に対しては、普通の態度です ))人間の弱さは私たち共通の問題であり、その代表者個人の問題ではありません。
さすがに番組の種類の話からは脱線してしまいましたが。このために別のブランチを立ち上げるべきでした。しかし、実用化の気配すらない純粋な学術的なものになるため、あまり意味があるとは思えません。
私が言っている意味は、 プログラム実行の 通常のロジックのことです。このようなロジックはMT4にあったもので、いい意味でMT5に引き継がなければならない。実は、これはMT4のデメリットではありません。この場合、MT5に対する優位性である。ですから、MT5を開発してMT4のことを早く忘れたいのであれば、MT4の良いところを取り入れてはいかがでしょうか。まあ、欠点は直して、せめて長所は改善しないとね。しかし、新たな欠点を持ち込むのは......。
それだ、俺たちは文句を言ってるんだ...。
まさに、通常のデスクトップアプリケーションにはないものを求めているのです。もし開発者が、すでに「箱から出して」あるこれらの機能をすべて行わなければ、MQLプログラムの書き手は、セキュリティの問題であれ実行速度であれ、デスクトップ開発のあらゆる魅力に常に直面することになります。複雑なことではなく、非常に疑問のある質問です。 この製品で 実装したことを、シンプルな腕時計の例で本当に再現してみてください。リストホイールではマウスでピリオドを変更し、TFを変更すると、変更内容が保存されるはずです。そして、何も複雑なことはないことがおわかりいただけると思います。そして、配列を渡す必要がある場合。そして、その「シンプルさ」を実感してください。おそらく、まだ実装していなければ、私自身もそう思うはずです。
メイン変数にピリオドを格納することの問題点は何でしょうか?
なぜ、異なるTFでインジケータを連続実行する間に、データの配列を転送する必要があるのでしょうか?