馬渕です。
Tietew wrote in [vcpp 00060600] Re: コントロールのサイズ変更での不具合:
>富豪的プログラミングの立場からは,無駄ではありません :-)
>むしろ,ユーザフレンドリなので,推奨されます。
描画されなきゃ、いくら OnSize() で処理したって意味ないでしょう。
Windows Messaging を分かっていっているのでしょうか。
それとも、軽くて速いプログラムよりも、
必要以上に重たいプログラムがユーザフレンドリーって
いいたいのでしょうか?
実際にその仕組みで作ってみればどっちが正しいか、分かることです。
私は実際に作ったものでは、全画面に近いサイズのドラッグでも
リアルタイム表示され、ストレスを全く感じません。CPU が 333Mhz
時代の話です。
神戸さんが「重たい」と感じたのは、「サイズの変動」と「描画」という
二つの全く独立したメッセージをセットで考えた節があるためです。
たとえば、ウィンドウが隠れているときにサイズが変わる(復元される)
ことだってあります。そういうときには WM_SIZE が来ても
WM_PAINT は来ないことがあります。
ところで、富豪的プログラミングってなんでしょうか?自分の高速CPU上で
満足にさえ動けばいいってことでしょうか?
>> (ドラッグでウィンドウの再描画をしない画面設定の場合がそう)
>
>だうと。
>ドラッグでウィンドウの描画を行わない設定(枠だけが移動する設定)
>の時,ドラッグ中には WM_SIZING (WM_WINDOWPOSCHANGING /
>WM_GETMINMAXINFO) だけがやってきます。そして,ユーザがボタンを放
>したとき初めて WM_SIZE (WM_WINDOWPOSCHANGED) がやってきます。
>
># これが OnSizing と OnSize の違いです>元質問者さん
思いっきり本末転倒のことを書いていますね。
Windows 3.1 時代からプログラムを書いている人間でないと
勘違いしそうな話です。
サイズ変更の時、ボタンを放さなくても WM_MOVE や
WM_SIZE は何度だって来ます。WM_PAINT が来ないだけです。
(カーネルが代わりに枠を再描画してくれるだけです)
昔のマシンは遅いから、必要になるまでなるべく WM_PAINT を
処理しないという発想です。
「ドラッグ中にウィンドウを表示する」という設定は、
WM_SIZE や WM_MOVE を発行するたびに、WM_PAINT を送る
かどうか、そういう違いです。WM_SIZE や WM_MOVE を
送る、送らないことではありません。
WM_SIZING はあくまでも、サイズ変動を監視するための、
WM_SIZE の前処理です。「そのサイズに変更させますか?
それとも強制的に別のサイズに変更しますか?」という目的の
ためにあるメッセージです。OKなら WM_SIZE を、ダメなら
WM_SIZE なし、変更なら、WM_SIZE に異なる値が入るという
性格のものです。移動中とか、そういう経過的なものでは
ありません。ボタンのリリースと関連づけてしまうと、
カーネルでのメッセージ処理はたいへんなことになります。
もう一度よくWindows API をよく読んでみてください。
いまどきのプログラマには、Windows API の仕組みを理解しなくても
プログラムが書けるから、内部処理まで考えて書く人間って
絶滅しかかっているかも(^^;
馬渕 茂
KOAH INTERACTIVE