そろそろうっとおしくなってきている気がするので非常に恐縮なのですがm(_ _)m

BS_DEFPUSHBUTTONの扱いについては少々クセがあるようです、過去に調べたメモの抜粋ですが

・BS_DEFPUSHBUTTONスタイルを設定するのは1つのコントロールだけ

・IDにIDOK/IDCANCELを設定した場合はIDOKのボタンにBS_DEFPUSHBUTTONが設定されていればそのままIsDialogMessageで処理されるが、それ以外のidを使用する場合自前Window (not ダイアログ) ではDM_GETDEFIDに応答する必要がある.

なおDM_GETDEFID/DM_SETDEFIDはDefDlgProcで処理される想定のものであり、上は自前でモーダルループを実装する場合の手順になる、DM_GETDEFID/DM_SETDEFIDはWS_USER/WM_USER+1が割り当てられておりIsDialogMessageはこれを発生する可能性があるのでWM_USER/WM_USER+1は使うべきでは無い.

なおIDOK/Enterについてはこれで良いが、IDCANCEL/Escapeについての別idでの再現方法は不明.

という事で上の話を守らないとフォーカスの移動等でデフォルトの黒枠が表示されなかったりといった問題が発生します、というかこの話自体自分でもすっかり忘れてましたが(^^;;;;

IDCANCELの挙動の別IDでの再現が分からなかった&面倒なんで自分はIDOK/IDCANCELを指定する方法しか使ってないです(笑)、、、というかダイアログ自体がリソースとコードの2箇所の修正が必要になる&IDをいちいち定義しなければならないのが面倒という具合なんで最近は殆ど使ってなかったんですけど、そういえば自前のペイントソフトのOKボタンにBS_DEFPUSHBUTTON設定してないですね、完全にBS_DEFPUSHBUTTONの存在自体忘れてました(大汗)

しかし、、、フィルタのダイアログの修正だけで50個近くあるのでめんどい、ライブラリにもデフォルトボタンの作成で関数1個追加しなきゃいけないし、更に現在メンテナンス中の全てのソフトに反映させると、、、あ゛ーorz

引き続きTANEさん所の6/18の話(^^;;;

Trackbarの件はもう少し混み入った話の模様、挙動を確認しましたがソースを見た所かなりのパネルでhbrBackgroundを設定しているので背景まで含めた再描画が頻繁に走ってしまってのチラつきのようにも見えます、コントロールの親windowの再描画 -> コントロール自体の再描画というカンジで. common controlのバージョンによって微妙に挙動が違うのは基本的にver5/6は別コードなんで無効矩形と再描画の発生のタイミングや頻度が違う為じゃないかと思います.

自分的にはhbrBackgroundはNULLにしてしまって最低限の描画のみWM_ERASEBKGNDとWS_CLIPCHILDRENを組み合わせて使っているのですが、背景描画は可能な限り最前面の子windowのみにしてコンテナなどその領域が子windowで隠れてしまうものについては最低限のはみ出す領域のみの消去に止めておくようなカンジで設定すると再描画時のチラつきは軽減できます. WS_CLIPCHILDRENが便利ですが、スクロールなんかの都合上それが上手く動かない場合は親windowの再描画で子windowの領域を無効矩形から除外するような処理を行う場合もあります.

# ちなみに挙動の話は例えばANSIで扱うとコモンコントロールのver5/6でeditコントロールのメッセージ結果自体違うものを返します(笑、、、えなかったりするX-<

Windowのアクティブの件はソースを見たカンジModalWindowの破棄(DestoryWindow) -> EnableWindow(親Window)とやっている気がするのですが (間違っていたらスミマセン) これだと一時的にアプリに有効なWindowが存在しない為Windowsのフォーカスマネージャが上手く処理できなくなります、ので正解はEnableWindow(親Window)を行ってからModalWindowのDestroyWindowを呼ぶのがモーダルマネージャの実装のセオリーになるんだそうです (by MSの中の人が書いた本より).

上のような必要性があるのでModal Dialogの終了はDestroyWindowでは無く専用のAPI(EndDialog)があるのだよ、とゆーよーな話が書いてありました(笑)

---------------

こちらは全くPCが壊れる気配が無いです、Win2kなんでそろそろ対応ソフトも少ない (とは言え最近は市販ソフトは殆ど使いませんし、半分隠遁状態なんでそれ程新しい開発環境を追う必要性も無い(ってそれでいーのか(爆死) ) のですが、これはこれで困ったものです(苦笑)

TANEさん所の6月16日ネタ、標準コントロールのTrackbar、確かに操作性的にはイマイチな部分はあるのだけど再描画周りってそんな変な挙動したかなーと気になったのでテストプログラム これ見る限りある程度の再描画は発生するのだけど、 それ程フリッカーが激しいという程でも無い気もしますが、、、ただ余りTrackbarを配置したWindowでリサイズ可能なものは作っていないので、他のコントロールが大量にあった場合とかは未確認ですが(^^;; もしかしたらリサイズ周辺のイベント呼び出しで不要な再描画が入ってしまっているとか?

Rebar(CoolBar)はほぼ全く使ってないので分かりませんm(_ _)m 個人的にドッキングするUIって嫌い(※1)なので特にニーズが無ければまず使わないシロモノなので(笑)

# 後、実害を明示出来ず、実装者の主義の部分もあるので書こうか迷ったのですが、windowのモーダル実行終了時に親windowをBringWindowToTopにするのはやらない方が良い気もします、普通はWindowsの標準処理で以前のwindowが復帰しますし、フォーカス周りの挙動はともすると自プロセス以外にも複数Windowへの通知などが絡んで割とデリケートな部分なので、多分目立った問題は無いとは思うんですけど. アプリで無用にSetForegroundWindowを呼ぶのと同種の危うさがあるというか. まぁ、個人的意見という事で(^^;;;;;;;;;

※1) 嫌いというと感情的な表現ですが、UIの場合漠然とした相対位置で記憶していたりするので、それにより画期的にワークフローが改善するのでなければ中途半端なカスタマイズ要素は無い方が良いというのが個人的な開発方針. 特にツールバーの位置なんて画面サイズに合わせてコロコロ位置が変わったりするので、それを取り合えず何でも並べて後はユーザーに投げっぱってのは単純にプログラマーのデザインの放棄な気がするワケで;-)

---------------

ここ暫くは何となく思い立ってFlash ActiveXのホストなんぞ書いていたり、ExternalInterfaceの呼び出しはShell View(IE)をホストする場合のSetExternalDispatch/GetExternalと違ってイベントシンク経由で_IShockwaveFlashEvents::FlashCallが呼び出されるカンジ.

でもってリクエストはXMLの形式で来るのでその為だけにCOMのXMLパーサを使ったりライブラリを探したりが面倒だったので、結局自前でXMLパーサを書いたり. 右クリック/メニューキーは結局上手い方法が無かったのでメッセージループでswfコンテナの子孫の場合にメッセージそのものを殺す (実際には送り先を親windowに変更してしまう) 形で対処してみたり.

swfのステージサイズは結局COM経由では安定したものが取れないのでswfを解析する形で実装したり、なおswfの圧縮は先頭8バイトを除いてzlibのdeflateそのまま. ついでにswfの構造を色々調べてみたり、基本はチャンク型なんだけど、サイズが厳しかった時代の産物でそこかしこにビットストリームな扱いが必要でウンザリしてみたり. それでも一応swfからリソースをぶっこ抜く事ができるようになったり、まー色々グダグダと、ただそんなに面白いものじゃありませんな(苦笑) まぁせいぜいswfをexeにしてexe起動の場合はファイルの保存やゲームパッドのサポートを追加する程度かなーみたいなそんなカンジ、まぁ飽きるまでという具合.

TANEさんとこのWindowクラスの話、ざっくりとしか読んでないですが、気になった個所を少々

・Windowクラスの管理はWM_CREATEでは無くWM_NCCREATEでやる方が良いかも、順序としてはWM_NCCREATE -> WM_CREATE -> WM_DESTROY -> WM_NCDESTROYだったと思います.

・コントロールのフォントはGetStockObject(DEFAULT_GUI_FONT)が使えます、後はGetSysColorBrushなんかも破棄しなくて良いので便利.

・Windowクラスのインスタンスを明示的に削除している個所が見当たらなかったのですが (見落としてたらスミマセン) GC任せとするとデストラクタでハッシュから除去しているけど、そもそもハッシュに登録されている限りGCでは削除されないのでは? (この辺D言語の仕様も余り詳しくないので間違っていたらスミマセン)

・上の話と絡んで、Windowハンドルの寿命とハッシュ内の登録情報の管理が一致していないと、後から作られたWindowのハンドル値が、前の破棄したハンドルと重複してた場合にマズいのでは、とか.

まぁこんな所でしょうか(^^;;

最近は自分はついぞ不精になって、複雑な処理以外はwndProc内に直書きしてしまってます、ドラッグ処理とかマウスイベントが分かれていると面倒&可読性が下がるし、ツール切り替えの実装なんかはメインWindowのwndProcからツールのwndProcに分岐させて必要なイベントだけフックさせるのでon〜ハンドラ式だと分岐コードだけでえらい事になるとか、まーそんな具合で(苦笑)

---------------

CMYKの話と絡んで、色々フォーマットを調べていた所、何時の間にか16bit floatがIEEE仕様になっていた.

という事で変換コードを書いてみたけど、精度域が3桁しか無いので色々微妙. 何と言うかまぁ、積極的に使うものじゃないなーというかそんな具合 :-<

それ以外にはTIFFのサンプルフォーマット指定にSAMPLEFORMAT_COMPLEXIEEEFPなるものを見つけて、何でもアリだなーと妙に感心したり、でも昔は一部の特殊なプログラムでしか使われていなかったSAMPLEFORMAT_IEEEFPは最近はHDR向けとして使われているとか、PhotoShopもCS2から対応しているとか. それ以外には各画像形式のICMプロファイルの埋め込み方法を調べてたり、まーそんなカンジでグダグダと.

いやまー、関連しているんで良い機会だから調べてるだけで、実際にはCMYKやカラープロファイルは実装しないと思うけど、自作ペイントソフトのpngのガンマルーチンすら外してる位だから、ちなみに色変換はICM APIに丸投げです(笑)

ここ数日はCMYKでのプレビューをいじる、実装要素としてはほぼ全て揃い、テスト組み込みでも問題無く動いてはいるが、実際に運用するには単にCMYKのプロファイル指定だけで無く、ある程度厳密なカラープロファイルの運用が求められるのでどーしたものか、といったカンジ.

カラープロファイルなんぞ、実際グラフィックソフトを使っている総人口からすれば9割の人間には意味が無いもので、無用な混乱を引き起こすという事では1割にとって有用でも9割にとっては害悪にしかならない、実際生半可な知識でのカラープロファイルの運用なんて目も当てられない状況であるし (実例はCMYKなどのキーワードで検索すれば腐る程出てくる).

同様にAdobeRGBの編集とかも同じ要素で実装はできるけど、これもまた殆どの人にとっては事態を更に無用にややこしく、分かり難くするだけにしかならない (そしてそれを回避するには、などという無用なノウハウが立ち上げられる事になる).

さて、どーしたものか :-<

# まぁ、ある程度はCMYKプレビューも家庭用プリンタでの印刷で変色し易い色を確認するのにも使える (6色で+LC,LMの場合は傾向は似ている) ので、実用性皆無とも言えないが.

# 同じような話としては画像のピクセルサイズとdpiの話も無用な混乱の元だわな、所詮コンピュータにとってはdpiなんて実体の無いメタデータに過ぎないワケで、まぁこちらはカラープロファイルよりは単純な話なのでまだマシではあるが、実際には印刷しないならピクセルサイズだけでdpiなんて要らないし、家庭用印刷ではどうせ勝手に拡大縮小が入るので目安程度の自己満足程度にしかならんのだけど、殆どのソフトにあってそれが元で混乱があるのを見るとやっぱり何か馬鹿げている気がする、まぁ世界の断裂ってヤツやね :-P

任意矩形で表現される作図的なパース座標の任意分割と座標変換のテスト

まぁこんなものかというカンジ、日記に載せるので小さな画面に押し込める形でかなり歪んで見えるが、2・3分割の補助線を引いてみるとちゃんとパース分割として成立しているのが分かると思う、ただ多分パース定規は実装しないと思うが(※1) ;-)

※1) 何と言うか、パース作成に必要な要素を一通り乗っけるとCAD的というか事務的というか事前計画的というか、ソフトの持つ印象が何とも堅苦しいor息苦しい代物になりそうなんで、せいぜいグリッド程度で気軽に扱える程度の実装に落としこめるならアリなんですけどね :-<

実装完了

まー何と言うかダラダラと、最近は日記を書くのも面倒なカンジで、困ったものだ.

その後あるソフトの体験版で同様の機能を試す、メッシュ変形自体はありがちな機能のようで意外と実装しているソフトは少ない、正直ワクワクしながら試したのだが、実際にはその余りの実装の酷さに呆れ返る事しきり、現時点で自作のものは公開する意思は無いので余り言えた義理では無いが、それでもこれは開いた口が塞がらぬという印象で、このソフトに限らず、とりあえずのチェックリストを埋めました的な実装およびそのような実装を行うプログラマの存在・人生(ぉ については、いずれは粛清^H^H是正されねばならぬと思う事しきり :-<

猫でも分かるWindowsプログラミングの次にやるべき事

Win32の勉強で少し前に友人に聞かれて即答できなかった内容、ふと別の友人プログラマと話していた時に、単機能のAPIの把握から実際にプログラムを書けるようになる所の開きは何処にあるかという話で出た内容を幾つか羅列.

・ウインドウハンドルにデータを結び付ける方法とその寿命管理
クラススタイルでWin32プログラムをやるなら必須、Cであっても複雑なプログラムはこの辺をやっておかないとまず無理

・カスタムコントロールの自作
ボタンのようなものでも良いので素のWindowからEnableWindow,SetFocus等に反応し、マウス操作に対して適切にキャプチャを行い、ダイアログマネージャ等と併用してもちゃんとフォーカス等が動作した上でライブラリ化して複数作成する場合にも通常コントロールの作成・管理と同程度の手間で済むものを作る.

・入力と画面更新の手順
入力に合わせて内部状態を更新し、再描画を発行する事でWM_PAINT内で全て更新するモデルでの実装を行う、当たり前の話なんだけど結構この辺の話が見えてないプログラマも多い、間違っても非常時以外はGetDCで描画なんてしちゃいけない.

・オンメモリのフレームバッファとしてのdibの使用と画面更新
これまた意外と当たり前なようで詳細が少ない話、GUIやコントロール描画で凝ったものを作る際の基本中の基本. 個人的には80年代の8bitマイコン時代を語るプログラマで、自作のフレームバッファクラス/ライブラリを持ってない輩は須らく全てパチモンだと思って良いです:-P

・モーダルマネージャの自前実装とスレッドごとのWindowsのメッセージキュー実装の把握
これまた意外と当たり前のようで資料の少ない話、フレームワークのコード等でしか実際のサンプルを見る機会は少ないが、細かいGUIの挙動を実装する場合任意の場所でのモーダル実行の実装やその時Windowに何が起きているのかの把握は必須. またSend/PostメッセージがWindowsによってどのようにキュー上やメッセージリスト に追加されて処理されているのかもちゃんと実装レベルで把握してないと変な落とし穴にはまり込んだりする羽目に.

とまーこんな所でしょうか、改めて見るとどれもこれも本当に基本的な、当たり前の話でしか無いのですが、意外とネットで見ていても情報が無い上に、自分の経験上アプリプログラマを名乗っていてこの辺全てちゃんと押さえているプログラマって余り見かけなかったりします.
(まぁ私の周囲が余りに悲惨なだけという可能性もあり全体の傾向とするには少々情報不足ではありますが)

それ以外には実際のライブラリの実装の例題として、作成されたコントロールの位置を記憶してWM_SIZEで自動で再配置を行うレイアウトマネージャとか、 仮想スクリーンの位置だけ設定しておけばスクロール座標だけでウインドウのスクロールが実装できるライブラリとか、もっと単純な所ではスプリッタコントロールの実装とか、まぁその辺をやっておくとダイアログまでは作れるんだけど、それ以上の 複雑なアプリとなると分からないといった状況を打開する鍵にはなるかもしれません.

実際慣れてくるとC#のGUIデザイナ程度でできる位のGUIはAPIでもそんなに手間がかからなくなったりします、ええ、いやマジで;-)

---------------

透明水彩としての表現力として例のレイヤーの計算式がどーのこーの、でこれが結果

元々の乗算合成での透明水彩表現だとこんな↓具合

なので、使い方によっては非常に効果的、透明水彩系の表現をした際に実際の絵の具に比べ発色が悪いという問題についてはほぼ解消可能&塗り込んだ時の予測という意味でも原色そのままなので問題無し. 無論万全というワケで無く、和紙等へのにじみという点はまだまだではあるが. ちなみに用法としては塗りのレイヤーと乾燥済みのレイヤーを同じモードで2枚用意して半透明描画 (SAIのマーカーにほぼ相当) で塗りレイヤーに描画、適当な所で乾燥済みのレイヤーに転写の繰り返しといった具合.

まぁ問題はPSDに保存するとレイヤーモードを再設定しなければならない所、そろそろ独自形式の保存の実装を検討する時期か.

---------------

まぁそんな具合で気付けば2011年、明けましておめでとうございます. 昨年は身内事で色々あった内容を書きたくなかったので殆ど日記は書いてませんでしたが、もうそれも過ぎた事、ぼちぼち以前のペースで動けるようにして行きたいと思ってますm(_ _)m

そうそう、車の免許取りました、東京では車を所有・維持するのは難しいですが、一応、ね.