カスタムコントロール

.NET

前にも書いたかもしれないけど、現在開発している.NETスマートクライアントアプリケーション用のフレームワークは、出来るだけ"カスタムコントロール"を用意せずに済ませたいと思っている。(カスタムコントロールとは、System.Windows.Formsネームスペースのクラスから派生した、自前の処理を書いたフォーム又はGUIコンポーネントのことを指す)

Delphiでアプリケーションを開発していた時は業務で必要なGUIは殆ど全てカスタムコントロールとして提供した。フレームワークの奔りのようなラィブラリィだったこともあるが、業務アプリのGUIで必要としている殆ど全ての機能をコンポーネントとして提供する狙いがあったからだ。その狙い自体は成功したが、結果として出来たGUI群は業務に依存した機能がどんどん追加されて、再利用どころかその業務専用のラィブラリィになってしまったのである。当時はレイヤを分離してGUIをビューを見立てることで完全に独立させる意識も薄かったものと思われる。

コントロールをビューと見立てる場合、業務に特化した機能の殆どはコントロールに書くべきでは無いことが解るし、書かないことでラィブラリィの再利用性が高くなる。また、昔は標準で用意されているコントロールではビューのバリエーションが不足していたことも、新たにコントロールを書く理由になったものだが(※1)最新の.NET2.0位になるとビューのバリエーションとしては殆どが標準で用意されているのも大きい。

実際、現時点でカスタムコントロールとして書いたのは、ガイダンスとエラーを同時に表示しつつ、プログレスバーを描画するステータスバー位なものである。それとて、いわゆるWM_PAINTメッセージを処理するハンドラを、自ら書くようなことは無かった。

.NET2.0で新たに追加された匿名デリゲート(Anonymous Delegate)もコントロールの外部から自由に制御コードを静的又は、動的に注入する口として使えるため、これも自前のコントロールを書いたり、Formクラスを継承して業務用のフォームを書く必要を減らしてくれる一助になっていると思う。

public new Control Control
{
    get { return this.control; }
    set
    {
        this.control = value;
        if (this.control != null)
        {
            this.control.Resize += delegate(object sender, EventArgs args)
            {
                //注入するリサイズイベント用コード
            };
            this.control.SizeChanged += delegate(object sender, EventArgs args)
            {
                //注入するサイズチェンジイベント用コード
            };
        }
    }
}

このような中だが、現在ひとつだけカスタムコントロールを書く理由が残っているように思う。それは「性能」だろう。そう思わせる位に.NET2.0の標準コントロールの描画は重いと感じることがあるのだ。皆どうしているのだろう。

※1.NET2.0で用意されているDataGridViewのような大規模なコントロールは買うか、内製するしかなかった。DelphiのVCLともなると当時の製品群では皆無だったので、泣きながら内製した。