RegisterHotKeyとObject.GetHashCode (その3)
RegisterHotKeyの第二パラメタのIDに何を使うか。やっと、このテーマにも結論が出そうだ。
どうやらオーバライドされる事に気をつけさえすれば、GetHashCodeを一意のIDとして使って良いのではないだろうか。
と思って、一度書いたクラスを書き直そうと思ったのだが、
なお、同書にも書いてあるが、Object.GetHashCodeの戻り値が一意であることが保たれているのは、同一AppDomain内だけであるという制限があるのでその点は注意が必要。Remotingを使っている状態などでは、やはり使えないということだ。
よく考えたら(よく考えなくても)、ホットキーは通常はO/S全体でグローバルなものだ。つまり、一つのホットキーの組合せはシステム全体で一意にすべきものだろう。ところが、.NET Frameworkにおいては、普通に作ってビルドしたアプリケーションは互いに別々なApPDomainを形成する訳で、そうするとやはりGetHashCodeは使えないことになる。
よって、やはり第二パラメタにはWin32のAtomを使うことにする。実装自体は過去にWM_COPYを使用したアプリケーション間通信でAtomを使ったので、その時に作ったユーティリティをそのまま使えそうだ。
結局こんな感じか
//ショートカット ushort id = Util.GetGlobalId(shortcut.ToString()); return RegisterHotKey(window.Handle, id, modkey, key);
何度も書くが、登録されたホットキーとAtomはシステムリソースなので、不要になったら開放しなくてはならない。
UnregisterHotKey(window.Handle, id); Util.ReleaseGlobalId(id);
今回に限らず顧客のリクエストに応えるには未だに.NETだけじゃ足りなくて、結局は低レベルのWin32に解決を求めることが多い。そうするとWin32と.NETのミスマッチを解決する必要が出てくる訳だが、これが結構時間がかかったりする。がしかし、これは一種の必要悪であり、今後も絶対に無くならないだろう。
Windows Vistaでは、.NET FrameworkとWxFと呼ばれるフレームワーク群によって、Win32をどんどんと後方へ押し遣って行くように仕向けるのだと思うが、それとは裏腹に、Win32は後10年は平気で使われている気がしてならない。仮にWPFが主流になったとしても、顧客の要望に応えるためには、結局はWin32が必要になってしまうのではないだろうか。(そういう顧客のリクエストをはなから無視すれば良いという意見もあるだろうが、まあ、自前のパッケージを書いている以外、つまりは一般的な受注開発ではまず無理だ。)
