記事"グラフィカルインタフェース I: ライブラリストラクチャの準備(チャプター 1)"についてのディスカッション - ページ 2

新しいコメント
 
Vasiliy Sokolov:
素晴らしい。できれば、グラフィカル・インターフェースの例をもっと写真で紹介してほしい。一般的に、このトピックはとても必要なものです。ずっと前に、標準ライブラリの ドキュメント化を始める必要がありました。

おそらく私は以前質問を誤解していたのだろう。

標準ライブラリのクラスを使うというのは、この種のクラスだけを意味していました：

つまり、プリミティブ・オブジェクトを作成したり、そのプロパティを取得したり変更したりできるクラスだ。

しかし、（はっきりさせておくが）私は、グラフィカル・インターフェースを作成するために提供されている部分を標準ライブラリから使用していない。これは完全に別のプロジェクトである。

追伸： たくさんの写真と例（最大限の詳細）があります。

 
Anatoli Kazharski:

私はこの前の質問を誤解していたかもしれません。

標準ライブラリのクラスを使うというのは、この種のクラスだけを意味していました：

つまり、プリミティブ・オブジェクトを作成したり、そのプロパティを取得したり変更したりできるクラスだ。

しかし、（はっきりさせておくが）私は、グラフィカル・インターフェースを作成するために提供されている部分を標準ライブラリから使用していない。これは完全に別のプロジェクトである。

追伸： たくさんの写真と例（最大限の詳細）があります。

なるほど。

なぜMQのGUIライブラリをベースにしなかったのですか？もしかしたら、その方が拡張や深化がしやすいのでは？

ちなみに、私は自分のGUIライブラリを持っているので、コンセプトを比較するのは面白いと思います。

 
Vasiliy Sokolov:

なるほど。

なぜMQのGUIライブラリをベースにしなかったのですか？もしかしたら、その方が拡張や深化がしやすかったのでは？

ちなみに、私は独自のGUIライブラリを持っているので、コンセプトを比較するのは面白いと思います。

この記事の一番最初に、私の考えを概説した。要約すると、（私の意見では）正しく理解するためには、プロジェクトを ゼロから始めるべきだということだ。

この連載の最初の14回を読めば、すでにコンセプトの適切な比較ができるようになると思う。ここには多くのニュアンスがあり、それを理解しなければ高いクオリティを達成することは不可能だった。

 
そう、おそらく2016年はインターフェイスの年になるだろう ))
 

興味深く、有益なプロジェクト だ！あなたの記事の出版を楽しみにしています！

それでは

 

こんにちは！

作成されたライブラリに慣れ親しんでいると、2つのことを感じます。一方では、ライブラリーの柔軟性と柔軟性に驚いています。もちろん、大きな「ありがとう」を言うことができます！

一方で、いくつかの点の実装は、新しいフォームを作成する 労働強度を増加させるため、不可解です。

たとえば、グラフ上でフォームを移動させる関数について考えてみよう。

この関数では、作成されたすべてのフォーム・オブジェクトを列挙する必要があります。なぜか？なぜなら、作成された要素はすべてフォーム自体のコンテナ（配列）に配置されるからです。なぜ関数の中で、作成されたすべての要素を列挙する必要があるのでしょうか？コンテナの周りをループして、すべての要素の座標を変更すればいいじゃないか。

同じことが他のメソッドにも当てはまります。例えば、Hide() 関数ではフォームの要素をループすることですべての要素を非表示にしますし、Delete() 関数ではすべての要素をバラバラに列挙します。不明確です。

このため、フォームに新しい要素を追加する際には、新しい要素をそれぞれ指定する必要があるSTANDARD関数をすべて覚えておかなければなりません。これは非常に不便です。同じことが要素へのフォーカスにも当てはまります。例えば、画像ベースのボタンでは "BmpFileOn "と "BmpFileOff "が指定されます。また、フォーカスの他のプロパティ（フレーム色、背景色、テキスト色、テキストサイズなど）を設定することもできます。そしてこの場合、フォーカス定義関数に記述する必要はなく、要素の配列を走査して、「フォーカス内」／「フォーカス外」のプロパティに従って、それぞれのプロパティを設定すればよい。

折りたたむ...

当初、ライブラリーは、フォームがヘッダーの下（上）に折りたたまれるように設計されています。同時に、ヘッダーはフォームがある場所に残ります。私は、作成されたフォームの標準的な動作、つまり、ウィンドウが最小化されたとき、ウィンドウは下に最小化され、ヘッダだけが（下に）残るように実装しようとしています。さらに、フォームの2つのモードを実装しようとしています：「標準」、「最小化」、そしてもちろん最小化です。

ボタンを作成する段階で、すでに上記のすべての問題に直面しました。まだ開発が始まったばかりなのに...。

また、作成した要素とそれに対する操作を格納するコンテナ（配列）は1つではなく、コンテナの階層構造を作った方が普遍的だと思う。つまり、フォーム全体に対して1つのコンテナを作成し、フォーム上で一般的な操作（移動、削除、非表示など）を実行できるようにします。このコンテナには、ヘッダー要素のコンテナとフォーム要素のコンテナの2つが含まれます。3つ目のコンテナも可能で、ベースメント・コンテナがあれば、それです。さらに、フォーム自体のコンテナは、フォーム上に要素を配置するためのブロックのコンテナを含むことができる。このような実装では、例えばフォームを最小化すると、フォームコンテナ自体の要素が削除され、ヘッダーコンテナの要素が移動するはずです。一般的なアクションを実行するときは、コンテナそのものに対して操作を行う。つまり、フォーム自体を移動させれば、フォーム（アプリケーション）全体の要素のコンテナも移動する。

作者が私の考えを理解してくれることを願っている。:)

繰り返しになりますが、この仕事は素晴らしく、有用で有益です。しかし、作者の表現から一歩でも離れると、困難が生じ始めます。もちろん、完全に普遍的な解決策はありません。しかし、ライブラリーのいくつかの一般的な標準機能は、本当に普遍的なものにすることができるだろう。

ありがとう、アレクセイ。

 
AlexBar3073:

......筆者が私の言いたいことを理解してくれることを願っている......。

私の言いたいことは明確だ。ありがとう。

ライブラリーはまだ開発中だ。最終バージョンには程遠く、多くの部分が最適化され開発される予定です。

最新版（2016.11.20）はこちらの記事からダウンロードできます：GUI X: Text Input Box, Picture Slider and Simple Controls (build 5).

 
Anatoli Kazharski:

言いたいことはわかった。ありがとう。

ライブラリーはまだ開発中です。最新版には程遠く、多くの部分が最適化され開発される予定です。

最新版（2016.11.20）はこちらの記事からダウンロードできます：GUI X: Text Input Box, Picture Slider and Simple Controls (build 5).

これが最後ではありません。:)mt4用の最新版をダウンロードして、その上にインターフェイスを構築しようとしています。しかし、mt5用のライブラリは、mt5特有のメカニズムが使われていなければ、mt4でも動作すると理解しています。

私が発言したこれらのコメントや提案がライブラリの次のバージョンに反映され、より柔軟で普遍的なものになると同時に、実用的なアプリケーションの観点からよりシンプルなものになることを願っています。ライブラリの開発中、私が提案したのと同じ、クラスの継承の「カスケード」メカニズムがフォーム要素の形成、つまりコンテナの継承に使われました。そして、子孫は（フォーム・アプリケーション全体の）グローバル・プロパティだけでなく、親のプロパティ（アンカー・ポイント、可視性、移動など）も使うことができます。:)

新しい記事のリリースとライブラリの開発を心待ちにしています。

ありがとう、アレクセイ。

 
AlexBar3073:

これが最後ではないことは分かっている。:)mt4用の最新版をダウンロードして、その上でインターフェイスを構築しようとしています。しかし、mt5用のライブラリは、mt5特有のメカニズムが使われていなければ、mt4でも動作すると理解しています。

MT4バージョンは私の側からは開発しません。MT5用のみです。

AlexBar3073：

私が発言したこれらのコメントや提案がライブラリの次のバージョンに反映され、より柔軟で普遍的なものになると同時に、実用の観点からよりシンプルなものになることを願っています。

最初は何も言えない。どうすればより良くなるかについては、長い間理論的に考えることができます。実際にテストしてみれば、すべてが明らかになるだろう。

 
Anatoli Kazharski:

MT4用のバージョンは私の方ではもう開発しません。MT5用のみです。

最初に何かを言うのは難しい。長い間、どうすればより良くなるかを理論的に考えることはできる。実際にテストしてみれば、すべてが明らかになるでしょう。

はい、私はすでにmt4のバージョンが開発されないことを読んだ - それはひどいことではありません。

まあ、テストだけが、より良いライブラリの作り方を示すことができるという事実は否定できない。しかし、OOPの観点からは、提案された方法は、実用的な実装の可能性が最も高い。:)

12345
新しいコメント