This article is the beginning of another series concerning development of graphical interfaces. Currently, there is not a single code library that would allow quick and easy creation of high quality graphical interfaces within MQL applications. By that, I mean the graphical interfaces that we are used to in familiar operating systems.
もちろんです。MQLで自分のGUIフレームワークを作るのに、過去にこのようなライブラリを作っていた経験も計算に入れずに、何ヶ月もかかりました。最も困難だったのはイベントではなく、アーキテクチャと、コードのデバッグがほとんど不可能だったことです。なぜなら、すべての入れ子と再帰に加えて、デバッグを開始するときにすでに無効になっているマウスの状態のためです。
ところで、私は数ヶ月前にこれらのライブラリを使ってMQにコラボレーションを提案しましたが、残念ながら返事すらもらえませんでした。しかし、実際のところ、標準のコントロール ライブラリは、実際に可能なことと比較すると、良い試みではありますが、悪い試みでもあるのです。もっといいものができるはずです。多分、私はこのライブラリをマーケットプレイスで提供すべきなのでしょうが、それのために全ドキュメントを書くという作業の束を恐れています。
これは全く疑問の余地がない。OOPは自然界の原理に基づいています。地球はあなたを養うのではなく、資源を提供するだけで、いつ、どこで、何を必要とするかはあなた次第なのです。
つまり、フレームワークを作るときは、リソースを提供することにだけ気を配ればいいということですか？それはわかるのですが、どうもその傾向が強すぎて、実践するのが難しいんです。
例えば、フレームワークを作るときに、ボタンとラジオボタン（ボタンコンテナの一種）を作ったとして、ラジオボタンを作るときに、依存オブジェクト（この場合はボタン）とどのように通信するかを考える傾向があるんです。これは手続き型プログラミングの癖なのですが、過去に手続き型からOOにシフトしたことがあれば、このケースで私が焦点を当てるべきことを明確に示すことができるでしょうか。なぜなら、私はボタン（従属オブジェクト）よりも、ラジオボタンに焦点を当てる傾向があるからです。
私は明確にしたかどうかわからない、それはフレームワークでレベルを作成するときに焦点を当てるために重要な ものを指摘することについての質問です。
どういうことなのか、言ってもらえますか？だいたいの感じはわかるんですが、よくわからないんです。
フレームワークを作るときは、リソースを提供することだけに気を配れ、ということでしょうか。それはわかるのですが、どうもその傾向が強すぎて、実践するのが難しいんです。
例えば、フレームワークを作るときに、ボタンとラジオボタン（ボタンコンテナの一種）を作ったとして、ラジオボタンを作るときに、依存オブジェクト（この場合はボタン）とどのように通信するかを考える傾向があるんです。これは手続き型プログラミングの癖なのですが、過去に手続き型からOOにシフトしたことがあれば、このケースで私が焦点を当てるべきことを明確に示すことができるでしょうか。なぜなら、私はボタン（従属オブジェクト）よりも、ラジオボタンに焦点を当てる傾向があるからです。
明確にしたわけではありませんが、フレームワークでレベルを作成する際に重視すべき点を指摘する質問です。
もしかしたら的外れかもしれませんが、私の意見を述べさせてください。
あなたは「理論」にこだわりすぎていて、誰かからの光を待っているのだと思います。完璧な解はなく、解があり、それを自分の経験や具体的なニーズから見つける必要があります。
このトピックは実用的なケースから始まり、それがOOPに関する曖昧な議論になったことを知っています。GUIに関する面白い連載が あるので、それを見て、標準ライブラリを使って、その記事のライブラリを使ってインターフェースを作ってみて、そのコードを勉強するとかしないとか......。
ただ、これ以上どうすればいいのか分からないので、提案だけしておきます。
もしかしたら的外れかもしれませんが、私の意見を述べさせてください。
あなたは「理論」に頼りすぎて、誰かからの光を待っているのではないでしょうか。完璧な解はなく、解があり、それを自分の経験や具体的なニーズから見つける必要があるのです。
このトピックは実用的なケースから始まり、それがOOPに関する曖昧な議論になったことを知っています。GUIについては面白い連載が あるので、それを見て、標準ライブラリを使ってインターフェースを作ってみたり、これらの記事のライブラリを使ったりして、コードを勉強してみるとかしないとか......。
ただ、これ以上どうすればいいのか分からないので、提案だけしておきます。
Alain、私はインターフェイスを作り、記事も読みました。
ここはOOを議論する場所ではないかもしれませんね。
私がこの議論を始めたのは、Doerkがトピックビギナーへの応答としてこのトピックを提示し、正しいOOアプローチについて話したからです。
トピックビギナー自身がDoerkのOOのプレゼンに興味を持ったのですから、ここで議論するのは自然なことだと思うのです。
理論的すぎるという指摘はもっともですが、正しいOOは理論を抜きにしては成り立たず、最終的には実用的なものになるというのが私の意見です。
私が苦労しているのはOOの正しい考え方ですが、ひょっとしたらDoerkさんは、私が提示した精神的な苦労を経験的に知っているかもしれないと思っただけなのです。
GUIに関する面白い連載が あるので、それを見て、標準ライブラリを使ってインターフェースを作ってみたり、これらの記事のライブラリを使って、コードを勉強してみたり...しないかな。
私はちょうどそれが何をするか見るためにそれをダウンロードしました。そして、最初の印象は、彼らが標準制御ライブラリでやったのと同じ悪い間違いをしたことを示しています。すでに最初の例では、1つのダイアログウィンドウで、CPU使用率を10%(未使用時)から50-65%(ロード時)に引き上げています。これは、作者がこのようなライブラリを開発するのに必要な経験を持っていないこと、そして、これが正しい方法であるはずがないことを示す最良の証拠と言えるでしょう。
なぜMQは、その方法を説明する代わりに、プロフェッショナルなGUIフレームワークを提供しないのか、私には理解できません。ほとんどのMQLプログラマーはEAやIndicatorを開発したいと思っているはずですが、そのようなことに煩わされたくはないのでしょう。
さらに、彼らの例のパネルはストラテジーテスターの中で死んでいますし、このようなGUIに関することはすべて、とにかく無茶苦茶なことなのです。これは、あなたやあなたが書いたものに対する批判ではなく、私自身が、MQLのために利用可能な、より良いパブリックなものがないことを知っているからです。
Alain、私はインターフェイスを作ったし、記事も読みました。
多分ここはOOについて議論する場所ではないでしょう、あなたの言う通りかもしれません。
私がこの議論を始めたのは、Doerkがトピックビギナーへの返答としてこのトピックを提示し、正しいOOアプローチについて話したからです。
トピックビギナー自身がDoerkのOOのプレゼンに興味を持ったのですから、ここで議論するのは自然なことだと思うのです。
理論的すぎるという指摘はもっともですが、正しいOOは理論を抜きにしては成り立たず、最終的には実用的なものになるというのが私の意見です。
私が苦労しているのはOOの正しい考え方ですが、ひょっとしたらDoerkさんは、私が提示した精神的な苦労を経験的に知っているかもしれないと思っただけなのです。
ここでOOPについて議論するのは問題ないでしょう。
でも、そんなことはどうでもいいんです。
ここでOOPについて議論するのは問題ないでしょう。
私は、「OOPは理論がないとできない」という意見には賛成できませんが、それは問題ではありません。
私は、それが何をするのか見るためにダウンロードしたところです。そして第一印象は、標準コントロールライブラリと同じ悪い間違いを犯していることを示しています。すでに最初の例では、1つのダイアログウィンドウで、CPU使用率を10%(未使用時)から50-65%(ロード時)に引き上げています。これは、作者がこのようなライブラリを開発するのに必要な経験を持っていないこと、そして、これが正しい方法であるはずがないことを示す最良の証拠と言えるでしょう。
なぜMQは、その方法を説明する代わりに、プロフェッショナルなGUIフレームワークを提供しないのか、私には理解できません。ほとんどのMQLプログラマーはEAやIndicatorを開発したいと思っているはずですが、そのようなことに煩わされたくはないのでしょう。
さらに、彼らの例のパネルはストラテジーテスターの中で死んでいますし、このようなGUIに関することはすべて、とにかく無茶苦茶なことなのです。これはあなたやあなたが書いたものに対する批判ではなく、私自身、MQLのために利用可能な、より良い公的なものがないことを知っています。
ドーク、君の言うことはもっともだが、私が言いたいのはそういうことじゃない。
このCPUの問題はなぜ起こるのか、具体的な例を書いて、何が問題なのかAnatoli（記事の著者）に説明すべきです。申し訳ないのですが、あなたが言ったことは、たとえ100％正しいとしても、ほとんど役に立ちません。あまりにも一般的で理論的 すぎるのです。悪気はないんです。
問題は、この問題があまりに複雑で、正確な指示を与えることができないことです。そのため、興味のある方にいくつかのアイデアと可能な方法を提供しようと思っています。残念ながら、私は記事を書いたり、完全に文書化されたライブラリを公開する時間がありません。申し訳ありません。