記事"カスタムグラフィックコントロールパート1：簡単なコントロールを作成する"についてのディスカッション

[MetaQuotes]

新しい記事 カスタムグラフィックコントロールパート1：簡単なコントロールを作成する はパブリッシュされました:

本稿では、グラフィックコントロールの一般的な原則を網羅します。グラフィックオブジェクトの作業を早く便利に行うためのツールを用意し、テキストや数値データの入力のために簡単なコントロールを作成する方法や、その使用方法の例を分析していきます。

作者: Dmitry Fedoseev

[---]

パート2の予定は？

[Dmitry Fedoseev]

sergeev:

第2部では何が予定されているのだろう？

第2部では標準コントロールの ライブラリ（チェックボックス、コンボボックス、スクロールバー、リスト、ラジオボタンなど10種類以上）、第3部ではコントロールを使ったフォームの作成。

[---]

イデオロギーは変わるのだろうか？

まずは3番目の部分、つまりコントロールを使って フォームを作るところから始めるべきだろう。

そして次のパート、つまり各要素の内部構造へと進む。

つまり、まず複合体が全体としてどのように機能するのか、子要素が親要素とどのようにメッセージやイベントをやりとりするのか、イデオロギーが一般的にどのように機能するのかについて、ユーザーを教育する。これは重要なことで、一般的なものから特定のものへ、つまり各特定要素の機微へと移行することが望ましいからである。

ついでに言うと、描画、つまり各要素がどのように描画されるかを強調すべきではありません（簡単に行うことはできますが、すべての要素をShow関数で描画させるので、ユーザーは各クラスのどこを見れば描画ブロックが表示されるかがわかります）。描画は、全プロセスのイデオロギーに比べれば、本当に何でもないことだ。

すべての要素がリンクされているフォームの準備できた例をいくつか示した方がいいだろう。

つまり、用意された例で、具体的なことを説明するのだ。

[Dmitry Fedoseev]

sergeev:

イデオロギーは変わるのだろうか？

第3部の金型作りから始めるべきだったかもしれない。

そして、各要素の内部構造へと徐々に移行していく。

イデオロギーとは何ですか？

形というのは、基本的にはXとYの座標でしかありません。

形から始めるとしたら、そこに何を書くか。「これは形です。ここにコントロールエレメントを 追加して、ここにそのイベントを処理します」と書くだろう。しかし、それがどんなコントロールエレメントで、何を表しているかは誰にもわからない。

コントロール・エレメントが1つしかないのに、2番目の部分にフォームを作ったとしても、それは指示的ではないし、美しくない。

[---]

Integer:

イデオロギーとは一体何なのか？

形とは本質的には何もない。

すぐ上の答えを拡大

その通りだ。そこが重要なんだ。重要なのは、出来事のやりとりのプロセスであり、全体としてのすべての要素の相互作用である。そしてこれは、要素ごとではなく、システム全体としての働きを示して初めて説明できる。

[---]

Integer:

コントロール・エレメントが1つしかないのに、2番目のパートでフォームを作るとしたら......。

フォームとコントロール・クラスはすでに用意できていますか？

[Dmitry Fedoseev]

sergeev:

すぐ上の答えを拡大。

その通りだ。そこがポイントで、形は何でもない。主なものは、イベント交換のプロセスと、全体としてのすべての要素の相互作用です。

フォームにはOKボタンとキャンセルボタンがあり、端末が再起動したときのためにデータを保存します。イベント処理、フォームをドラッグする機能、最小化する機能などがある。

[Dmitry Fedoseev]

sergeev:
フォームとコントロール・クラスの準備はできていますか？

かなりできています。最初はサブウィンドウなしで作っていたんだけど、今はサブウィンドウで動くように全部作り直してるんだ。

[Mykola Demko]

sergeev:

イデオロギーは変わるのだろうか？

たぶん、私たちは3番目のパート、つまりコントロールを使ってフォームを作るところから始めるべきだったのでしょう。

そして次のパート、つまり各要素の内部構造へと進む。

つまり、まず複合体が全体としてどのように機能するのか、子要素と親要素の間でメッセージやイベントがどのようにやり取りされるのか、イデオロギーが一般的にどのように機能するのかについて、ユーザーを教育する。これは重要なことで、一般的なものから特定のものへ、つまり各特定要素の機微へと移行することが望ましいからである。

ところで--レンダリング、つまり各要素がどのように描かれているかを強調するのは、やってはいけないことだ。形がどのように機能し、すべての要素がどのようにつながっているのか、いくつかの例を示すほうがいい。ドローイングは、全過程のイデオロギーに比べれば、本当に何でもないことなのだ。

まさか、単純なコードを作成する例はすでに十分にあるのに、クラスの階層構造をうまく作れなかったり、少なくとも普遍的で変形しやすい製品のスキームを簡単に実装できなかったりすることはないだろう。MQの標準的なクラスでさえ、可能性をあらかじめ敷設することによってプログラムを書くことを複雑にしていることが多い。

[---]

Integer:
フォームにはOKボタンとキャンセルボタンがあり、端末の再起動に備えてデータを保存する。イベント処理、フォームをドラッグする機能、最小化する機能もある。

OK。これはとてもいい。

後編で高レベルの機能を説明すれば、記事のコンポーネントがより早く使われるようになるだろう。
私なら、フォーム＋ボタン（＋入力ボックス）から始めて、第3部でリストやメニューなどの特定のコントロール・コンポーネントについて説明します。

結局のところ、課題はそのようなコントロールの書き方を教えることなのだ。しかし、それらを挿入するフォームがない限り、記事はそのような壮大で必要な効果を与えないだろう。
それに、2番目の記事ですでにForm+Button（ラジオ、プッシュ、チェックの3種類という意味）+EditBoxを与えれば、ユーザーはクラスを全体として見ることができ、自分自身のコントロールを独立して作成できるようになる。