2006-09-20

鳥オーナー契約

http://www.asahi.com/international/update/0920/021.html
鳥取のダチョウに乗ってみたい…。
http://www.dacho.co.jp/
というか食ってみたい。
お金を貯めたら小さなダチョウ牧場を作るのも良いなぁ。
http://www.dacho.co.jp/dacho/kachiku/index.htm
でも飼ってるダチョウを間引いて屠殺とかしたら逆襲に遭いそうな気がしてくる。
http://ja.wikipedia.org/wiki/%E5%B1%A0%E6%AE%BA

2006-09-20

IEBars

http://www.mimec.org/articles/iebars
MFCで使うメニューとツールバーではこれがやっぱり良さげ。メニューを開いた後にカーソルをドラッグして子メニューの上でWM_LBUTTONUPした時に、選択の反応にならないのが通常のメニューと挙動が違ってちょっとだけ不満。あと、HOTとかDISABLEの絵を自動的に作ってくれるのはありがたいけど、自前でセットもしたい。しかし32bitのIMAGELISTを作る処理を自前で書く気力が無い事を考えると、無料で使えるだけ全然感謝。

ツールバーにコンボボックスとかを置く場合、Separatorに変化させて無反応にしてその上にCreateするけど、なんだか作ったWindowの下にSeparatorの線が見えて気になっていた。
http://park17.wakwak.com/~dragoon/toolbar2.htm
描画をコントロールしなくちゃ駄目なのね。。当たり前だけど思い付かなかった。

2006-09-20

Windows Vista

Windowsはこれから新規の標準Controlをどうしていくんだろう？VistaではDirectX10ベースでGPUで描画するんだろうけれど、どうなってるのかさっぱり。あと次のOfficeはRibbonBarが採用されるのでMenuは消えていく運命なんだろうか？でもまぁ旧来通りのやり方でもまぁなんとかなるさ…。

TaskDialog

http://windowssdk.msdn.microsoft.com/en-us/library/ms650910.aspx
見慣れない言葉なので検索してみたらVistaで新設されるみたいだ。
http://www.ailight.jp/blog/sha256/archive/2005/10/07/9879.aspx

Control Spy v2.0

http://windowssdk.msdn.microsoft.com/en-us/library/ms649774.aspx
こんなのがあるの知らなかった。

Shell and Common Controls Versions

http://windowssdk.msdn.microsoft.com/en-us/library/ms649534.aspx
IE7とかIE8が登場した時にコモンコントロールのDLLは新しくなるんだろうか？

What's New in the Windows Vista Shell

http://windowssdk.msdn.microsoft.com/en-us/library/ms674790.aspx
標準のShellはどんどん強力になるなぁ。これに則って作るのが便利で使いやすいアプリケーションを作る王道な気もする…。

- - -

Windowsの標準コントロールは、もうある程度部品は揃っていて、歴史も10年以上あるので、似たようなのをどんどん増やしていったりExとかSuperとか適当に名前付けて拡張したのを増やしていったら収拾が付かなくて混乱を引き起こしちゃうのかな。でも小奇麗なManaged Codeは重いしメモリ食うし未整備なとこ多いし…。

2006-09-20

ウィンドウのサブクラス化

サブクラス化の処理は猫Cとかで昔読んだ気がするけど、面倒なので自分では手を付けていないでMFCとかATLやWTLに完全に頼っている。Vistaの調査でMSDNを眺めていたら気付いたんだけれど、ComCtl32.dllのversion 6以降では、サブクラス関連のAPIが追加されているようだ。
http://windowssdk.msdn.microsoft.com/en-us/library/ms649784.aspx
自分でサブクラス化の面倒を見る手間が何やら省ける感じ。というかAPIのサブクラス化の処理をリッチに面倒を見てくれる、というべきなんだろうか？理解が足りなくて上手く言葉に出来ない。

ATLとウィンドウプロシージャ

http://hp.vector.co.jp/authors/VA022575/c/msgmap.html
サブクラス化ってAPIではどうやるんだったっけな、と検索して調べているうちに、上のページの内容が理解したくなった。ページを参考にしてATLのソースを読んだり考えたりしたところ、ATLの、ウィンドウメッセージを処理するウィンドウプロシージャを、何とかしてインスタンスのスコープに回す仕組みが、何とか理解出来た。

staticなStartWindowProcというのを各ウィンドウクラスのウィンドウプロシージャとして設定する。設定処理は実際にどこに書かれてるかは今回の調査外。
初回に呼び出されるウィンドウプロシージャ（StartWindowProc）の中で行われる処理は以下の通り
- thisを取得するのはATLのアプリケーションモジュールにとりあえず任せる。（上のページを見てみるとLinkedListに格納してるようだ。）
- 各instance毎に用意されるmemberのthunkに実行コードを作らせる。（実行コードを摩り替える処理を行わせる）
- そのthunkをウィンドウのWindowProcとして再設定する。（SetWindowLongPtr）
- thunkの実行コードはHWNDをthisに置き換え、別のstaticなWindowProcを呼び出す内容になっている。staticなWindowProcのアドレスはともかく、thisのアドレスは、ウィンドウプロシージャが動いている間は有効にしなければならないんだろう。そもそもthunkとかが死んでいる時にはinstanceも死んでいるだろうし…。
- staticなWindowProcの内容は、引数のHWNDがthisなのでキャストして得た後は、ProcessWindowMessageを呼んだりとかの、ある程度ユーザーが使う部分に直接繋がっている感じな内容。
2回目以降に呼び出されるウィンドウプロシージャは、thunk。thunkでは、HWNDのパラメータにあたるものをthisにして、設定されたウィンドウプロシージャのアドレスにジャンプ。
SetWindowLongPtrされたWindowProcはthunkのものなので、thunkの実行コードが基本的に呼び出される。つまり毎回instanceのthunkの実行コードを経て（設定したので当然なんだろうけど）ウィンドウプロシージャが呼び出される。

もし自分でインスタンスのスコープでメッセージ処理を行う仕組みを作る必要に迫られたら、アプリケーションモジュールでmapみたいな領域を確保して、HWNDをキーにして、thisとウィンドウプロシージャのアドレスをメンバに持つ構造体のinstanceを、毎回ウィンドウプロシージャで検索して取得するやり方を思い付く。ATLのは実行コード中にinstanceのアドレスを書いてしまうある意味ハックというか乱暴なやり方。検索コストが無さそう。コードの実行領域とかが少し膨らむ気はする。

しかしそもそもWindowProcのパラメータが最小限必要な４つしか無い事が、変な仕組みをアプリケーション側で用意する必要が出てくる理由な気がする。ここに何かもう一個数字が入る仕組みにすればアプリ側では、thisとかを取りやすそうなのに。でもWindowProcってかなり頻繁に呼ばれるから、それだとあまりパフォーマンス的に頂けないのかな。。あと昔はC言語の時代だったので、C++のthisの都合なんて知らないって事なのかもしれない。

話を元に戻す

新しいSUBCLASSPROCは、
http://windowssdk.msdn.microsoft.com/en-us/library/ms649784.aspx
パラメータが増えているので、時代が富豪化を許す時代になったという事だろうか？WindowsVistaではRAMは最低1GBの時代だろうし。

サブクラス化は既にウィンドウクラスが登録されたウィンドウの挙動をカスタマイズする為のもので新規ウィンドウを作る時は従来通りのパラメータが少ないウィンドウプロシージャを呼び出して下さりやがるAPIを使うしか無いのかな？サブクラス化しなおせば良いんだろうか？こういう新しく出てきた補助関数はコストはどれくらい従来のものに比べて掛かるんだろうか？

それはともかく判り易い利用例を発見。
http://blogs.msdn.com/oldnewthing/archive/2003/11/14/55678.aspx

挙動が単純な、掛け合わせても問題無いメッセージ処理のカスタマイズを適用するのがOSのAPIで楽に出来る感じだろうか。カスタマイズするロジックを記述するのが楽になるかも。