記事"カスタムグラフィックコントロール パート3. フォーム"についてのディスカッション

[MetaQuotes]

新しい記事 カスタムグラフィックコントロール パート3. フォーム はパブリッシュされました:

この記事はグラフィックコントロールに関する3つの記事の最後になります。代表的なグラフィカルインターフェースである、フォームの作成や、他のコントロールとの併用の仕方についても紹介します。コントロールライブラリーにはFormクラスの他に、CFrame、CButton、CLabelといったクラスが加えられました。

作者: Dmitry Fedoseev

[Konstantin Gruzdev]

ディミトリ、有益で良い作品だ。第4部について提案があります：「フォームウィザード」または「ビジュアルフォームエディター」についてどう思いますか？

[---]

尊敬するよ、ディミトリ。君は素晴らしい仕事をしてくれた。

次のバージョンのv4 クラスのために、いくつかの批判を受け入れてください。

1. 基本的なプロジェクトでは、抽象化が十分ではありません。各コントロールが独立したユニットとして機能することがわかりました。その結果、例えば、それらを組み合わせて配列にすることはできません。

2.2.各要素の各クラスは、大体において、独自の関数セットを持っている。これは良いことではない。共通の祖先が1つあり、その関数は子孫で単純にオーバーライドされるべきです。特に、現在のクラスには同じ名前の関数がたくさんあるのだから。共通の祖先を作ることを止める理由は何だろう？

3. もし基本クラスが現れたら、イベント処理をすべてフォームの外に置くのではなく、子孫の中に隠すことが可能になる。オブジェクトの中にイベントのカスケードを作ることができる（ウェブにおけるCSSに似ている）。

特に、ボタンを押したときの「ナッジ」と、要素の状態に応じて押されたときのインタラクティブな反応が気に入った。

追記
そして、マルチレベルメニューはまだ完成していない、それについての別の記事は必要ない、新しい記事を書くためにこのような小さなタスクのためにあまりにも太っ腹。v4ではアップグレードだけにしておこう。
CTreeCtrlツリークラスは、MTキットで提供されている記事https://www.mql5.com/ja/articles/272、またはCTreeNodeから取ることができます。

[---]

Lizar:

ディミトリ、有益で良い作品だ。第4部について提案があります：「フォームウィザード」または「ビジュアル・フォーム・エディター」についてどう思いますか？

個人的には前向きに考えています。ビジュアルはオブジェクトの配置を単純化するだけです。きちんとやれば、作成したオブジェクトのコード生成、変数やクラスのオブジェクトへのバインディングが必要になる。そして最も重要なのはイベント処理 だ。

しかし、これらの非抽象クラスではそれができない。非常に手作業なのだ。多くの場所で、新しく作られたオブジェクトとその処理を書く必要がある。
例えば、イベントについては、システムとユーザーへのそのような分割はありません - Draw（基本システム）とOnDrawのように - 独自の描画を持つユーザーからの追加。

他の構造では（例えばJoomla！）OnDrawカスタム関数は1つだけではありません。そして、BeforDrawとAfterDrawの2つに分かれています。つまり、プログラマはシステムイベントEVENT_DRAWを処理することができます - システム描画の開始前と終了後の両方。

[Dmitry Fedoseev]

sergeev:

尊敬するよ、ディミトリ。君は素晴らしい仕事をしてくれた。

次のバージョンのv4 クラスのために、いくつかの批判を受け入れてください。

1. 基本的なプロジェクトでは、抽象化が十分ではありません。各コントロールが独立したユニットとして機能することがわかりました。その結果、例えば、それらを組み合わせて配列にすることはできません。

2.2.各要素の各クラスは、大体において、独自の関数セットを持っている。これは良いことではない。共通の祖先が1つあり、その関数は子孫で単純にオーバーライドされるべきです。特に、現在のクラスには同じ名前の関数がたくさんあるのだから。共通の祖先を作ることを止める理由は何だろう？

3. もし基本クラスが現れたら、イベント処理をすべてフォームの外に置くのではなく、子孫の中に隠すことが可能になる。オブジェクトの中にイベントのカスケードを作ることができる（ウェブにおけるCSSに似ている）。

特に、ボタンを押したときの「ナッジ」と、要素の状態に応じて押されたときのインタラクティブな反応が気に入った。

追記
4.マルチレベル・メニューはまだ完成していないが、それに関する別の記事は必要ない。
CTreeCtrlツリークラスは、記事https://www.mql5.com/ja/articles/272、またはMTキットで提供されているCTreeNodeから取ることができます。

1- シングルタイプのコントロールを配列にまとめることができる。なぜ異種のコントロールを1つの配列に集めたいのですか？

2.基本クラス（すべてのコントロールに対して1つ）を使用する場合、サブクラスが持つことができるすべてのメソッドを持たなければなりません。独立したクラスでは、（開発中に）メソッドのドロップダウンリストに、そのクラスに実際に存在するメソッドだけが表示されます。これは非常に重要なポイントだと私は思う。誰かが座っていて、垂直スクロールバーのSetWidth()メソッドを呼び出そうとするのを想像できます。

2つ目の論点は、すべてのクラスがdoxygen用にコメントされていることです。もしベースクラスとサブクラスがあれば、ドキュメンテーションでそれほど明白な構造化は行われません。

私は、"目をつぶって "使えるような既成のソリューションを作るようにしています。新しいコントロールの作成プロセスをスピードアップするために、すべての必須メソッドを含むテンプレートを使用することができます。

3.よく理解できません。コントロールの中に別のコントロールがある場合、そのコントロールのイベント処理は非表示になります。いずれにしても、コントロールごとにEvent()を呼び出す必要があります。

4.よくわかりませんが、たぶん...。メニュー作成用に特別に設計された独自のクラスがあり、AddNode()を呼び出す必要はなく、AddItem()が呼び出され、アイテムの名前が始まるスペースの数によってレベルが決定されます。ツリーを作成するプロセスは非常にわかりやすい。ここまでは、コメントとキー・コントロールでの表示で動作します。一般的に、いくつかのツリーメニューを作ることができます：1) 通常のメインメニューのようにドロップダウンのタブを持つもの、2) 1つのタブの項目とトップへのパスを表示するもの、3) ツリー表示を持つもの（windos explorerのようなもの）。

[Dmitry Fedoseev]

sergeev:

1.個人的にはポジティブに捉えている。可視化はオブジェクトの配置を単純化するだけだ。きちんとやれば、作成したオブジェクトのコード生成、変数やクラスをオブジェクトにバインドする必要がある。そして最も重要なのは、イベントの処理 だ。

2.しかし、これらの非抽象クラスではそれができない。非常に手作業なのだ。
。 イベントについては、例えば、Draw（基本システム）とOnDraw（独自の描画を持つユーザーからの追加）のように、システムとユーザーに分けるようなことはありません。

他の構造（例えばJoomla！）では、1つのカスタム関数OnDrawだけではありません。そして、BeforDrawとAfterDrawの2つに分かれています。つまり、プログラマはシステムイベントEVENT_DRAWを、システム描画の開始前と終了後の両方で扱うことができます。

1.コントロールのイベントを処理するコードを自動的に生成し、HScrollBar1_OnChange()...のようなすべてのコントロールのイベント関数を取得することが可能になる。

2.例えば、プログラムによって値が設定された場合、ユーザーによって値が入力されたときのみイベントが発生します。これは最低限必要なもので、余分なものは何もない。そうでないと、独学でプログラミングを学ぶ人がイベントで溢れかえってしまう。

[Dmitry Fedoseev]

Lizar:

ディミトリ、有益で良い作品だ。第4部に提案があります：「フォームウィザード」または「ビジュアル・フォーム・エディター」です。 どう思われますか？

前向きです。汗をほとんどかかず、大砲なしでできる方法はもうわかっています。ロシュが気にしなければ、休み明けには可能だろう。

[Sergey Pavlov]

Lizar:

...パート4への提案があります：「フォームウィザード "か "ビジュアル・フォーム・エディター "です。 どう思いますか？

「すべてはすでに我々の前に盗まれている」（Y作戦）。

[---]

Integer:

1.シングルタイプのコントロールをアレイに組み立てることができる。なぜ異なるタイプのコントロールを1つの配列に集めるのか？

すべてを1つのループにまとめ、イベント・サービスにおいて特定のタイプを排除するため。

2.2.基本クラス（すべてのコントロールに対して1つ）を使用する場合、どのサブクラスも持つことができるすべてのメソッドを持たなければならない。独立したクラスでは、（開発中に）メソッドのドロップダウンリストで、そのクラスに実際に存在するメソッドだけを持つことになります。これは非常に重要なポイントだと私は思う。誰かが座っていて、垂直スクロールバーのSetWidth()メソッドを呼び出そうとしているところを想像してみてほしい。

基底クラスの関数はすべて、最小限の一般的な機能を持つ空のストッパーです。たとえ誰かが無意識のうちに要素に無関係な関数を呼び出したとしても、悪いことは何も起こらない。これがOOPの力だ。ポリモーフィズム。

つ目の論点は、すべてのクラスはdoxygenのためにコメントされている、ということだ。

あるにはある。:)

[Dmitry Fedoseev]

sergeev:

1. すべてを1つのループにまとめ、イベント・サービスにおける特定の型を取り除く。

2.ポイントは、基本クラスには特定のアクションの関数の実装がないことだ。基本クラスのすべての関数は、最小限の一般的な機能を持つ空のストッパーである。たとえ誰かが、ある要素に無関係な関数を無意識に呼び出したとしても、悪いことはまったく起こらない。これがOOPの力だ。しかし、ポリモーフィズムは 違う。

3.そうなる。ただ、それは違うものになる...。:)

1.以上ですか？2.のメソッドダンプをいじくり回すために？

代替案

1)手動で各クラスのEvent()コールを追加する必要性（これはマウスで1行コピーし、ポイントの左に数文字を変更することで構成される）と同時に、各クラスのメソッドのリストでは、我々はこのクラスに対応する唯一の作業メソッドを持って、ポイントをクリックし、リストがポップアップ表示され、すべてが明確である。

2) 全クラスのEvent()を自動処理し、一方ではOnChartEvent()から1つの関数を呼び出す必要がある。また、deinitでポインタを破棄しなければならない。

すべてのEvent()が1つのループで処理されるべき理由、各コントロールがそのEvent()に対して独自のアクションを持つべき理由、コントロールは値を入力するためだけでなく、画面上ですべてを動かしたりちらつかせたりするためだけでなく、入力された値をプログラムで使用するためでもある（主な範囲）。

3.あるコントロールのメソッドの約半分をドキュメントのある場所で読み、残りの半分を別の場所で読まなければなりません。

[Mykola Demko]

Integer:

1.それだけ？このために、ポイント2、つまりメソッドのダンピングをいじるのか？

代替案です：

1）手動で各クラスのEvent()コールを追加する必要性（これは、マウスで1行をコピーし、ポイントの左に数文字を変更することで構成されています）と同時に、各クラスのメソッドのリストでは、我々はこのクラスに対応する唯一の作業メソッドを持って、ポイントをクリックし、リストが落ち、すべてが明確である。

2）すべてのクラスのEvent()の自動処理、一方、1つの関数はまだOnChartEvent()から呼び出される必要があります。また、deinitでポインタを破棄しなければならない。

すべてのEvent()が1つのループで処理されるべき理由、各コントロールがそのEvent()に対して独自のアクションを持つべき理由、コントロールは値を入力するためだけでなく、画面上ですべてを動かしたりちらつかせたりするためだけでなく、入力された値をプログラムで使用するためでもある（主な範囲）。

3.あるコントロールのメソッドの約半分をドキュメントのある場所で読み、残りの半分を別の場所で読まなければなりません。

あなたはすべてを正しく行っています。

MEの可能性を考えると、非常に便利で、総キッチュ時代の日本のミニマリズム、すべてがそこにあり、余計なものは何もない。

オブジェクトをループさせたい人は、postfixシェルを実装して、そこに好きなように書くことができる。