データを表形式（マトリックス）で表示し編集できるコントロールだけど、コントロールのカテゴリはデータに属しているよね。ここがポイントだよ。つまり、データベースと連携するためのコントロールとして提供されているんだ。
「先輩、私はプログラムでデータをセットしていますけど･･･」
そうだね、DataGridViewを普通のコントロールと同じようにプログラムベースで扱うことからはじめる人もいるんだ。実は、僕もそうだったんだ。計測データを表形式に表示するのによく使っていて、そのときはデータを高速周期で更新するようなことに使っていたな。やりたいことができればそれで十分だった。だから、そのときには深追いはしなかったんだ。
「それじゃ先輩は、いつDataGridViewの全貌解明に目覚めたんですか？」
切っ掛けはデータベースとの自動連携かな。これをデータバインディングって言うんだけど、この機能を使うとデータベースのテーブルとDataGridViewの結びつきがVisual StudioのWizardやプロパティ設定だけでほとんどできてしまうんだ。つまりデータベースへの更新処理以外は、じぶんでプログラムを書く必要がないということに衝撃を受けたんだ。これが切っ掛けでまとめてみようと思うようになった気がするよ。
知らないと損をする＝遠回りをする、無駄なものを作ってしまう
この考えは、ライブラリを使う上での基本中の基本だよね。
何ができるのか、どこまでできるのか、どこからカストマイズしなければならないのか。
これらを知るためには、全体像を意識しながらいろんな視点で試してみるしかないよね。体系的な説明がないのだから、一つ一つを試しながら―じぶんで―体系化するしかない。でも、結構手間がかかるから、目先の問題解決ができれば終わり。こんな繰り返しだと多少知識は増えるけどモヤモヤはなくならない。
DataGridViewのプロパティ設定が、実際どこにどう影響するのかはプログラムを書いて確認しなければならないよね。
「そうなんです。私いつもやってます。これかなと思うプロパティの値を変えたり列挙値を一つ一つ変えて試したりするんです。でも、あるときはうまくいくのに、時々期待通りにならないときもあります。そのときはネットで探してコードを利用して何とか使えるようにするんですけど･･･」
そのときのプログラムや結果はどうしているの？
「えっと、期待通りの方法になればいいので、途中のプログラムは残していません。結果は頭の中です」
普通そうだよね。でも、この方法だとDataGridViewの全貌を理解するのはとても難しくなるので、違う発想で実験プログラムを考えてみたんだ。
Visual Studioのデザイナは、列名は表示してくれるけどデータは表示してくれない。
だから、プロパティ値による変化はデータを表示してみるまで分からない。
それなら、「任意のデータの設定」と「リアルタイムな設定確認」ができるプログラムを作ればいいじゃないかってね。