 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Win API / April 2007Hooking WM_CHAR
Hi! Okay, all this talk about various hook methods (as well as the recent visits by MSFT PSS! <g>) leads me to post this here. I'm hooking Microsoft Word's editting window (class: "_Wwg") from an axDLL that's invoked via Word VBA, so it's certainly in-process. The hook is set, and working very well. Except, I hate to say "doesn't work" but, except that no WM_CHAR messages are coming through. I can watch them buzz by using Spy++ on the same window (verified by hWnd), and I'm getting the corresponding WM_KEYDOWN and WM_KEYUP messages, but no WM_CHAR at all. Any thoughts on why that might be? I can fairly well rule out (right?) the hooking code, because the same routines used within a standard VB application, watching a standard Textbox, catch WM_CHAR without issue. Thanks... Karl  Signature.NET: It's About Trust! http://vfred.mvps.org > I'm hooking Microsoft Word's editting window (class: "_Wwg") from an axDLL that's > invoked via Word VBA, so it's certainly in-process. The hook is set, and working [quoted text clipped - 6 lines] > hooking code, because the same routines used within a standard VB application, > watching a standard Textbox, catch WM_CHAR without issue. I probably should've said, this is just Subclassing 101. Similar to this code: Option Explicit Private Const WM_KEYDOWN As Long = &H100 Private Const WM_KEYUP As Long = &H101 Private Const WM_CHAR As Long = &H102 Implements IHookSink Private Sub Form_Load() Call HookWindow(Text1.hWnd, Me) End Sub Private Sub Form_Unload(Cancel As Integer) Call UnhookWindow(Text1.hWnd) End Sub Private Function IHookSink_WindowProc(hWnd As Long, msg As Long, wp As Long, lp As Long) As Long Dim txt As String Dim mTxt As String Dim cTxt As String Select Case msg Case WM_KEYDOWN mTxt = "WM_KEYDOWN" Case WM_KEYUP mTxt = "WM_KEYUP" Case WM_CHAR mTxt = "WM_CHAR" cTxt = "'" & Chr$(wp) & "'" Case Else mTxt = "&h" & Hex$(msg) End Select If Len(mTxt) = 0 Then mTxt = "&h" & Hex$(msg) If Len(cTxt) = 0 Then cTxt = CStr(wp) txt = "hWnd: &h" & Hex$(hWnd) & ", msg: " & mTxt & _ ", wp: " & cTxt & ", lp: " & lp & vbCrLf With Text2 .SelStart = Len(.Text) .SelText = txt End With IHookSink_WindowProc = InvokeWindowProc(hWnd, msg, wp, lp) End Function Using the MHookMe.bas and IHookSink.cls files found here: http://vb.mvps.org/samples/HookMe Signature.NET: It's About Trust! http://vfred.mvps.org > Private Const WM_KEYDOWN As Long = &H100 > Private Const WM_KEYUP As Long = &H101 > Private Const WM_CHAR As Long = &H102 This is a wild guess... had a bit of a time "whipping up" something that works in VBA (darn foreign language! Where the heck's form_load?).... anyway, does spy happen to report WM_UNICHAR messages going to that window? That message is new to XP and is UTF-32, instead of UTF-16, so.... Private Const WM_UNICHAR = &h109 SignatureKen Halter - MS-MVP-VB - Please keep all discussions in the groups.. In Loving Memory - http://www.vbsight.com/Remembrance.htm > Private Const WM_UNICHAR = &h109 Nope. Actually got the subclassing to work. No such message processed. WM_CHAR either. Spy++ sees them. SignatureKen Halter - MS-MVP-VB - Please keep all discussions in the groups.. In Loving Memory - http://www.vbsight.com/Remembrance.htm >> Private Const WM_UNICHAR = &h109 > > Nope. Actually got the subclassing to work. No such message processed. > WM_CHAR either. Spy++ sees them. So we have Repro, huh? :-( WTH? Signature.NET: It's About Trust! http://vfred.mvps.org >> Private Const WM_KEYDOWN As Long = &H100 >> Private Const WM_KEYUP As Long = &H101 >> Private Const WM_CHAR As Long = &H102 > > This is a wild guess... had a bit of a time "whipping up" something that > works in VBA (darn foreign language! Where the heck's form_load?).... Heh, it's actually kinda fun, once you get some of that oddball stuff outta the way. Still hassles with the near total lack of hWnds, and lots of other hurdles, that are reminiscent of the VB1 days! Good stuff. (You found Form_Initialize, right? Also, most Office apps have some form of AutoOpen/AutoExec type of routine that fires when new docs open.) > anyway, does spy happen to report WM_UNICHAR messages going to that window? > That message is new to XP and is UTF-32, instead of UTF-16, so.... > > Private Const WM_UNICHAR = &h109 Not familiar with that, but see you ruled it out in another post. I didn't see it in Spy++ either, but I wasn't really looking for it, myself. Signature.NET: It's About Trust! http://vfred.mvps.org Hi Karl, It looks like Word's internal implementation detail. I don't have any idea on it and it's probably not supported by Microsoft Customer Support and Service. Sorry. Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. > It looks like Word's internal implementation detail. I don't have any idea > on it and it's probably not supported by Microsoft Customer Support and > Service. Sorry. Eh? Word's internal implementation detail? So you're suggesting Word has set a higher hook? What do you (or anyone else) think about trying that WH_GETMESSAGE hook discussed in another recent thread? Are you guessing, or can you state, that this isn't a topic that can be discussed (by PSS) under the guise of a "managed" post? Inquiring mind... Karl Signature.NET: It's About Trust! http://vfred.mvps.org > Hi! > [quoted text clipped - 11 lines] > code, because the same routines used within a standard VB application, watching a > standard Textbox, catch WM_CHAR without issue. Hi Karl, see that if you call 'DispatchMessage' within your IHookSink_WindowProc function, you will receive the WM_CHAR message, for example: '*********** ... Funct IHookSink_WindowProc(hWnd As Long, msg As Long, ... ... Select case msg Case WM_KEYDOWN mTxt = "WM_KEYDOWN" Dim Message As MSG GetMessage Message, hWnd, 0&, 0& DispatchMessage Message Case WM_KEYUP mTxt = "WM_KEYUP" Case WM_CHAR mTxt = "WM_CHAR" cTxt = "'" & Chr$(wp) & "'" ... ... '*********** Ok, in that case, although you send the WM_KEYDOWN message to the original window procedure after or before 'DispatchMessage', the keystroke is posted to the "_WwG" window, but not processed. I don't know why... SignatureGreetings - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ( ! ) Preceding answers in Google: http://groups.google.com/group/microsoft.public.vb.winapi ( i ) Temperance in the forum: http://www.microsoft.com/communities/conduct/default.mspx - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - That's a really interesting observation. Actually, a couple of them. I suppose the keystroke isn't being processed in the _Wwg window for the same reason as we're seeing WM_CHAR now in our hook? Not really sure how, or even if, I can use this. But I sure do appreciate the opportunity to chew on it for awhile. Very interesting. Thanks! Signature.NET: It's About Trust! http://vfred.mvps.org >> Hi! >> [quoted text clipped - 40 lines] > window procedure after or before 'DispatchMessage', the keystroke is posted to > the "_WwG" window, but not processed. I don't know why... By any chance, is the WM_CHAR message you're looking for nested? Spy++ would show this. I'm not sure if it's the same for InProc subclassing, but I've encountered this problem before out of process...messages not being returned because they were nested in other messages. - Kev | Hi! | [quoted text clipped - 13 lines] | | Thanks... Karl > By any chance, is the WM_CHAR message you're looking for nested? Spy++ > would show this. Doesn't appear to be, nope. Thanks, though! Signature.NET: It's About Trust! http://vfred.mvps.org |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.