■

フックできました。当初の目論見どおりの実装。
SetWindowsHookEx 関数
ローカルフック
まだ開いてあった参照ページ。
とくに下の解説はコードコピーしてみたら動いた。
肝はフック先の指定とreturn ture;だと思います。
僕はてっきりキューリストから引き抜いたメッセージをHookProc()で握りつぶす形なんだと思ってたんですが
HookProc()でtrue以外を返すとメッセージはキューリストに残り、そのままDefProc()に流れていくようです。
他ではメッセージを破棄するなら0を返せとあったのですが･･･、0およびfalseではメッセージの破棄は行われませんでした。
また、CallNextHookEx()は、単に次のHookProc()に投げるのであって、
キューリストにあるメッセージは変化させず、HookProc()が見つからなかった場合DefProc()に投げるわけではないのでした。
そこがわかってなかったので動かない動かないと悩んでいました。
イメージでいうと、
キューリストという棚のキューを、手に持ってうろうろしているのか、そのメモだけ持ってうろうろしているのかわかってなかった。
処理済というメモをはっつけて返すってのが必要だったんですが、僕はメモだけ書き換えて止まっていたわけです。
あとは今回モードレスダイアログ内の1つのエディットボックスでのみの処理でしたが、
昨日まではフックハンドルの設置先をダイアログボックスそのものにしていたのに対し、今日はエディットボックスに直接設置しました。
違いを確認はしていませんが、おそらくダイアログ全体にフックがかかっていたものが、特定のEditBox限定のフックになったはず。
これで元々の処理が復旧しました。

今回詰んだ原因はCallNextHookEx()の処理内容が不透明だったことと、フックしたメッセージの破棄方法がわからなかったこと。
CNHE()はかならず呼び出さなければならないとまで書いてあったので最後まで呼び出してたんですが、
PostMessage()のあとに呼び出して入力が重複したのを見て、「ああ、いらないんだ」と。
つまりはキューリストへの干渉方法を誤認していたということでしょうか。
調べてもろくに出てこなかったから当然の詰みポイントなんだけど。キュー破棄ってやっぱりやっちゃダメなのかな。

さて、そんで元々どんなバグが出てたんだっけか。調べてこないと。