横幅がぐりぐり変わり、複数行表示可能なエディットコントロールを、文字列にあわせて、高さを調節したい。
DrawText 関数に、 DT_CALCRECT フラグを設定することで、指定した幅に収まる文字列を表示するのに必要な矩形の取得だけをすることができる(描画されない)。
コレを使ってコントロールの高さを計算し直せば実現できる。
上のエディットコントロールを書き換えると、その文字列が下のエディットコントロールに反映され、サイズが変更されるようなサンプルを作った。
ばりばり ATL/WTL 使ったコードだが、基本的に普通にWin32API呼んでも同じようにできる。
継承されるクラスに仮想デストラクタを書かなくてはならない理由として、
よく、ポリモーフィズムを使った場合に、派生クラスのデストラクタが実行されない理由が挙げられる。
"継承 仮想デストラクタ" でググった結果
そうすると、「派生クラスにデストラクタ書かなければ当然仮想デストラクタでなくてもいい」と思いがちだが、
実はそんなことは全然無い。
前回突然オーバーライドと隠ぺいの話をしたのは、
今回の話につなげるため。
CDialogResizeは便利だが、
チェインを使ってコレを処理してしまうと、
その後にWM_SIZEの処理をすることができなくなってしまう。
(チェインする前に捕まえて、 bHadled=FALSE することは可能)
じゃあCDialogResizeを継承して、処理した後にreturnしないようにすればよいのだが、
OnSize関数は仮想関数ではないので、書き換えることができない。
ところが、そのOnSizeを呼んでいるメッセージマップの実態である、
ProcessWindowMessage関数は、(BEGIN_MSG_MAPマクロの中身)
チェインからのみで、CDialogResize内部からは呼ばれていないので、
これを隠ぺいしてしまえば、CDialogResizeのProcessWindowMessageは呼ばれない。
つまり、WM_SIZEを捕まえてもreturnしないProcessWindowMessageを書けばいいのだ。
よくある仮想関数を使ったポリモーフィズム(多様性)の例とは少し違うけど
(複数の種類の派生クラスのアドレスを、親クラスのポインタに代入するやつ)、
メソッドをオーバーライドした場合と、隠ぺいした場合の動作の違いを例示すると、
こんな感じのソースになる。 続きを読む
最近、簡潔さとヘッダだけで動く手軽さ、動作の速さに出力バイナリの小ささから、
ATL/WTLに若干ハマっている。
WM_SIZEを処理するとCDialogResizeが動かないという
初歩的すぎるミスを犯したのでメモメモ。