どうやらちゃんとWindowsInstallerを利用してインストールしても、レジストリに登録失敗するケースがあるみたい。
今回のケースではTabCtl32.ocxとMSFlxGrd.ocxがおかしくなっていた。再度Regsvr32.exeで登録しなおすことで問題は解決できたんだけど・・・。ネット上を見ていると、このほかにもWinSock周りで同様の現象がでるみたい。
UACをOFFにした状態でインストール、その後UACをONにしたりしても同じような状況になるって話もでてるね。
なんか特定のコンポーネントに由来した問題のような気もするな・・・。
ContextMenuStripを利用してちょっとしたメニューを出したりすることはよくあるんだけど、その発生元がDataGridViewになった場合はちょっと手間が必要になる。
というのも、DataGridView.ContextMenuStripプロパティで設定したものは、DataGridView全体に対して有効になるので、例えば列ヘッダ（ColumnHeader）や行ヘッダ（RowHeader）でContextMenuStripを切り替えたいなんて時には、ちょっとだけ細工が必要になるんだよね。
列ヘッダで独自にContextMenuStripを使う場合は、DataGridViewColumn.HeaderCell.ContextMenuStrip、と下っていって設定する。それで今のところ最もベターなロジック記述場所はというと、DataGridView.ColumnAddedイベントの中。
Columnが追加された際に発生するイベントごとにContextMenuStripを指定してあげればいいかな、と思われ。
単発プログラムでなく汎用的に使う場合とかなら、DataGridView.OnColumnAddedメソッドをオーバーライドして対応するのがベターかな。
行ヘッダの場合も似たような事情で、DataGridViewRow.HeaderCell.ContextMenuStrip、となる。
列ヘッダの場合と異なるのは、「今存在する全ての行に対して設定する必要がある」というところ。なのでベターな記述場所はDataGridView.RowsAddedイベントまたはDataGridView.OnRowsAddedメソッドとなると思う。
コンストラクタとかでTabStopにTrueを設定しておかないと、Tabキーを押した際にフォーカス遷移がただしく行われなくなるんだねぇ・・・。
考えてみれば当たり前なんだけど、思いっきり失念していたのでメモ。
どうやらFree版ではVista対応を行わない様子。
久々にサイトをのぞいてみると、レイアウトが思い切り変更されて、Rev4.3 Release!みたいな宣伝が。
んで、そっち系統はちゃんとVista対応しているんだよねぇ・・・。
FreeEditionはRev4.1で取り残されているし。切捨て時だな、これは。
最近β２がリリースされた、検索ソリューション用のサーバアプリ・・・つーか、扱いはSharePointServiceみたいなもんだな、これ。
どうやらEnterpriseSearch的なことができるようになる、ということらしいんだけど、英語サイトしかないのでまだ詳しく見てないｗ
一時期NamazuとKakasi使って社内情報に対する検索って（隠れて）用意したことはあったけど、おそらく到着地点は同じだろうね。あとはどれくらい使いやすいか、とどこまで検索できるか、ってところかな？
Tracが落ちる、というかApacheが例外吐いてなおかつJITデバッガを起動しようとしてくれやがる件で、ためしにJITデバッガ自体を無効にしてみた。忘れないために手を入れたところをメモ。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
この2つのレジストリキーを削除。
VisualStudioのインストールによってJITデバッガが有効になってしまい、今までキャッチしていなかった例外をキャッチして、デバッグダイアログを表示してしまう、ってのが事の本質だなぁ。
インストールした、というけどサーバー上に入れていたVisualStudioって、SqlServerのReportingService用のヤツでVBもC#もインストールしていないから実質デバッグできないヤツなんだよね。そういう判断をしてJITデバッガのスイッチが設定されていればいいんだけど・・・問答無用でＯｎにしてくれているので、Apacheが例外はいたときにダイアログが出てしまい、OK押下まで再起動しない → 落ちている、という状況になっているワケだ。
これで大丈夫になることを切に願うｗ
久々にVB6の修正をやっていて気づいた。
VB6のコレクションにはClearメソッドがない・・・。
うわー、単純だけど地味に効いてくるなぁ・・・。よくCollectionの拡張しないでやっていたね、自分。
C#3.0の話題を出したときに、少しだけでていたラムダ式。
CodeZineでサンプルがでていたのでちょっと張っておく。
Common Lispでのラムダ式の一例
(setf f #'(lambda (x) (expt 2 x))) (funcall f 10)
おびただしい量の括弧です。しかし、C# 3.0のラムダ式も負けてはいません。次のようになります。
カッコいいラムダ式の一例
Func<int, int> f = (((x)=>((((x)>10))?(((x)+x)):((x*(x))))));
f( 9 );
これ、なんていう正規表現？可読性の「か」の字もねぇぞ！
[HOWTO] ADO プログラムからのセッション プーリングの実装
なんでいまさら・・・と思ってみてみたら、Ado.Netじゃなくて純粋にADOだった。つまるところ、既存のVB6資産でも有効にできるってとこだねぇ。といってもウチの社内では「セッションプーリング」を判っている人はいないだろうから、多分今まで通り「ＡＰ起動時に接続、終了時に解放」という流れはそのままなんだろうなぁ。
まぁ自分もプーリング知るまでは、それしかない、と思っていたからあまり強くはいえないｗ
しかし接続文字列で指定できたとはねぇ・・・意外とまだ知られていない（公表されていない）設定があるんじゃないのかな？
業務アプリ作っていると必ずといっていいほど、話題になりやすいのがEnterキー制御。
昔からの習慣で、Enter押下で次の項目へカーソルを移動、というのが多いんだよね。それ自体は特に否定も肯定もしないけど。
ただ、その機能をDataGridViewに追加しようとする前に、ちょっとだけ考えてみて欲しい。
Enter押下→次のセル、だけでいいのかどうか？
画面によってはEnterで次コントロールというのがあるだろうし、下のセルへ移動させるのもあると思う。そのあたりを踏まえてどう拡張するかってのを考えて欲しい。そのあたりを踏まえていれば、あとあと「えー」なんて文句をいいたくなる事も減ると思うｗ
実際の対処なんて、大したことはないんだよね。
ProcessDialogKeyメソッド、ProcessDataGridViewKeyメソッド、ProcessRightKeyメソッドあたりを調べてもらえばわかると思うけど、このあたりで「Enterの際にはセル（またはコントロール）を移動する」というロジックにしてあげればＯＫ。
ひっかかるとしたら、編集状態がからむとき。
EndEditメソッドを呼び出して、その結果ＯＫなら移動してあげる、とかそういう制御は必要だろうね。