TreeGridViewを用意したはいいけれど、VisualStyleを利用していない環境では思いっきり例外投げてしまうのが発覚。例外見て、「そりゃそうだわなぁ」なんて思える内容なんだけど、実際にはちょっと困ったことが。
VisualStyleを適用している際に表示するモノってのはSystem.Windows.Forms.VisualStyles.VisualStyleElementからたどっていってレンダリングできるんだよな。ところが適用していない場合に表示するモノってのが見つからない。個人的には適用していてもしてなくても同じロジックで取れるとありがたいんだけど・・・。
高望みか、これは。
今回のお仕事は、出荷状況の都合でOffice2007になることが正式に決定。いやぁ、これでCOMを利用した制御から逃れられるｗ
となると、課題になるのがOfficeのファイルフォーマットの入手かな？それと、ライブラリのところから２００３→２００７に変更しないと・・・。
あれ、そういえば2003と2007って同居した時にメソッドの拡張やらが行われるからちと問題があった記憶が・・・。まぁいいか。メソッドたたいてファイル操作すること自体がなくなるんだし・・・。
追記（15：49）
ちくしょう、英語でしかドキュメントが入手できないっ！！
こういうソリューションが無償で提供されているっていうのが、ものすごい脅威なんだよねぇ。なにしろ拡張部分ってのはVisualStudioを利用してWebパーツとして作成できるんだから。実際にweb上でも、SharePointService（またはOfficeSharePointServer2007）を利用して構築されたサイトってのも見受けられるし。
同じようなグループウェアも色々あるけど、拡張性やら何やらを考えると「システム屋に向いている」のはSharePoint系だなぁ、と思う。ユーザー向けなのはサイボウズだとかDeskNetsとかだろうけど。
以前にある程度実用的に用意できたサブエディタだけど、ここ最近色々と問題が発覚。そこで断念していた「ちゃんとしたサブエディタ」の設計と実装を始めることに。
DataGridViewコントロールの仕組みとして、編集コントロールをホストするタイプの物はIDataGridViewEditingControlを継承している必要があるのと、「ホストされるコントロールを継承している」必要があるんだよね。MSDNなどのサンプルも全てそうなっている。でもやりたいこととしては、「ＡＰ実装者側で自由にサブエディタのGUIやロジックを記述できるようにする」ということなので、ホストされるコントロールの継承、というのが今回は行えないんだよな。
んじゃあどうしましょ、というところで今考えているのが編集時にイベントやロジックを全て受け継ぐというか、トラップして制御を委任するだとかそういった制御。イベントだけだとまだ問題ないんだよね。イベント管理のコレクションを元にやってあげれば恐らくできそう。コントロールの配置とかも問題ないかな。
ただその割に、うまくいきそうでいかないんだよなぁ。何か見落としているか、間違ってそうな予感が満載。イヤな感じだ・・・。
昨日のTabIndexはなんとかうまくいった。大体想定したとおりに動いてくれたので良かった・・・。
今日出た問題の中にDataGridViewTextBoxCellのWrapMode問題があったなぁ。WrapMode=Trueとしたときだけ例外が発生するという。Reflcterで追っかけてみると、確かにWrapMode=Trueとした場合のロジックで問題がありそうな箇所が発見できた。セルの編集済み書式を取得するメソッドで明示的にStringを返していないといけなかったみたいで・・・。でもこれってWrapModeにTrueを指定したときだけなんだよね。NotSetやFalseをセットした場合は今回みたいな例外は発生しない。
DataGridViewTextBoxCellを継承しているコントロール全てに関連する問題だけど、これは仕様なのかバグなのか微妙だな・・・。なんでセルの値に対してToStringしないでCStrかけているんだろう？？
今までほおっておいた、TabIndex問題にようやく取りかかってみた。
TabIndex問題はVB6までと.NetでTabIndexのルールが変わり、直属のコンテナが別であれば値の重複は可能、というところ。
今のところ考えている手段はControlAdddedイベントの際に、別途用意したArrayListの派生クラスにコントロール名とTabIndexを保持させて、ついでに実際の状態と同じように名称とかを保持していく方法。
そんなもんで、今まであまり気にしていなかったSortメソッド関連を色々調査してみることに。
ICompare～とかを継承してTabIndex順にソートさせる下準備もしたんで、明日あたりはうまいこといってくれるといいなぁ。
何とか形になったDataGridViewでのサブエディタ。でも正直言うと、綺麗な構造にはなっていないんだよね。IDataGridViewEditingControlを継承した形で行うのが一番ベターなんだけど。今回はそこまでは手が回らなかった・・・。
そこにさえ目をつむれば、セルの編集開始と同時にサブエディタが表示され、サブエディタ上の処理は個別にコーディングできるようにはしたし、キー制御も親元から引き継いで処理されるようにはしたから結構満足。
これで残った大きい問題は・・・フィルタ処理だけ、かな。アンバウンドな時の処理ってのは非常に厄介なんだよなぁ・・・。
DataGridViewの基本機能の中でもくせ者中のくせ者、コンボボックス。
最初は全く持って例外が発生する理由がわからずに利用を断念していたんだけど、ここに来てようやく解決。.Netのコンボボックスの仕様とまったくもって違う仕様だったもんで、結構頭悩んだなぁ。独自クラスをItemsコレクションに放り込むまでは何ともないくせに、そのセルを編集やらなんやらしようとした瞬間に例外を放り投げてくれます。
結局DataGridViewComboBoxCellクラスを継承して独自セルを用意することで対応。ポイントとなるのは、値を表示する時と値から中身を用意するとき。表示は問題ないんだよね、この時点でセルのValueには独自クラスが入っているから。
ちょっと考えたのは値から中身を用意する方だったけど、よく考えてみるとColumn側で中身の候補は保持されているんだよね。なもんで、これも解決・・・と行きたかったんだけど、実は全てアンバウンドな状態じゃないと使えないんだよなぁ、これ。
バウンド時のロジックは気が向いたら入れておこう・・・。
DataGridViewはいじりがいのあるコントロールなんだけど、いかんせん敷居が高いというか、調べないといけないことが多い割に資料が少ないのが難点だなぁ。
今現在手をつけていないのは、前にもかいたフィルタ機能と最近あがってきたセルのサブエディタの実装。セルを拡張してサブエディタをホストするようにすればいいんだ、というのはわかるんだけど。まだ試してもいないので、実際にEditingControl関連を継承してサブエディタを実装できるのかなぁ？
これができると面白いんだけどね。まぁセルのイベントを利用して表示する方法では実現できている以上、どうにかできるんだろうけど。時間がまったくもって足りないことをのぞけば。