一応ですが、NO.101730 の”試し”が仰られている症状なのであれば、
以下サンプルのようにするとRichで「勝手にinputのような入力バーみたいなものが」と言われるものが消えませんか？
#include "modclbk3.hsp"
#include "kernel32.as"
#include "user32.as"
; リッチエディット
LoadLibrary "Msftedit.DLL"
winobj "RICHEDIT50W", "hoge", 0, 0x50b00004/*WS_CHILD|WS_VISIBLE|WS_BORDER|WS_VSCROLL|WS_HSCROLL|ES_MULTILINE*/, ginfo_winx, ginfo_winy
hwnd_edit = objinfo_hwnd(stat) : SetFocus hwnd_edit
; キャラクタフォーマット(仮で文字を赤くしとく)
chara_format2 = 84, 0x40000000/*CFM_COLOR*/, 0, 0, 0, 0x0000FF/*BBGGRR*/
sendmsg hwnd_edit, 0x444/*EM_SETCHARFORMAT*/, 0x4/*SCF_ALL*/, varptr(chara_format2)
; コールバックとサブクラス化
cbl = *CB : newclbk3 pcbl, 4, cbl
def_edit_proc = GetWindowLong(hwnd_edit, $FFFFFFFC/*GWL_WNDPROC*/)
SetWindowLong hwnd_edit, $FFFFFFFC/*GWL_WNDPROC*/, pcbl
stop
*CB
dupptr msg, lparam, wparam*4, 4; WinProc(HWND hwnd,UINT msg,WPARAM wp,LPARAM lp)
switch msg.1
case 0x0100 /*WM_KEYDOWN*/
vk = MapVirtualKey((msg.3>>16)&$ff,1)
if vk = 0x0D/*VK_RETURN*/ {
if ime = 0 : title "改行"
if ime = 1 : title "IME確定"
}
swbreak
case 0x010D /*WM_IME_STARTCOMPOSITION*/
ime = 1
swbreak
case 0x010E /*WM_IME_ENDCOMPOSITION*/
ime = 0
swbreak
default
swbreak
swend
CallWindowProc def_edit_proc, msg.0, msg.1, msg.2, msg.3
return stat
もし、そうであればIMEのメッセージ処理をRichのプロシージャに任せるのではなく、
デフォルトウインドウプロシージャに任せているのでは？と思われました。
ですから、Irisawaさんのマシン語とmodclbk3.hspとは直接関係ない問題かと考えられまして、
解説したいのですが、どちらもマシン語使っており元のソースが分からない為、
逆アセンブルしないと実装の実態は分からず、かなり骨が折れそうなので私には説明が難しいです。
状況があまり理解できておらず、当てずっぽうで申し訳ないです。。。
IMEの状態のフラグ管理はしてしまいますが、掲題のEnterの見分けはおそらく出来ていると思いますので、
この辺りで失礼いたします。
キーフックでのENTERキーについて
