Earle F. Philhower III wrote:
Howdy Harold, At 11:45 PM 5/30/2003 -0400, you wrote:
Any reason we shouldn't install a message hook when the user presses and holds a mouse button or modifier key?
I'm not sure what you mean by this, do a mouse capture? This may change the semantics,
because then any drop-target window won't get any mouse messages since only one window
is allowed to see the mouse moves/buttons.
No no, you do it with a message hook, like here:
http://www.codeproject.com/dll/trackuseridle.asp
I have written a message hook before that trapped all keyboard input and played morse code over the system speaker. Obviously, morse code is really hard to distinquish at 30 wpm! However, the hook worked just fine. We would have to have a seperate DLL that was installed in the hook chain... and it would be a good idea to make that DLL either a MinGW or MSVCRT DLL, rather than having it depend upon Cygwin. The reasoning for that is that hooks, if written poorly, can effect the whole system. However, they are just fine if kept small and fast.
On a related note, what is up with winmultiwindowwindow.c/winTopLevelWindowProc()/WM[NC]MOUSELEAVE and the SetTimer call? This must have been something that Kensuke did without me looking too closely :) It looks like it is used to move the X cursor out of the screen view when the user moves the mouse out of the X window... but it never calls KillTimer in the processing of WM_TIMER, which is strange. It looks like this could also be used to move the mouse cursor if it shows up over another X window... but that should be handled by the WM_MOUSEMOVE processing for that new window.
Do you see any reason we can't get rid of these timers? I would really like to avoid them if possible.
I think what he was trying to do was to update the mouse position in the root window when
the mouse isn't over any X window, since you only get mousemoves if the mouse is over your
window. Removing the timers would kill things like xeyes and the drag-n-drop icon movements
in some of the KDE/QT/whatever apps. In multi-window-mode the root window would then only
get messages when the mouse was inside the client area of one of the apps...
Okay, this would work with hooks too.
Even if he doesn't KillTimer, since he is reusing the event id it shouldn't cause any
kind of leak. And he does kill it on a mousemove on the initiating window.
Weird, when I did a search for KillTimer I didn't find anything. I must have missed it. In any case, what I was looking for was a KillTimer call win WM_MOUSEMOVE, which is there. No worries.
However I think he has a bug here, it seems he will create a timer for each
X window, not one for the entire application. You can test this by restarting the
server and running xeyes. Move your cursor around on the desktop, outside the window
and see how the eyes only update once per second or so. Now, open up 20 x terms and
move your mouse through each, just to start their timers. Finally, with those 20
windows up move your mouse outside them on the Windoze desktop and you'll
notice the eyes are following in real time, much faster than before. As bugs go
it's pretty benign, and would take another global variable to hold the timer ID
to fix...
Yes! That was what I was thinking too.
The global variable that he was using as a timer id should have been a constant, however, we don't need to specify a timer id when passing a NULL hwnd to SetTimer, so I changed the global variable to track the value returned by SetTimer. This value is then passed to KillTimer to destroy the timer when we see client mouse movement. This is great because it eliminates lots of timers that could show up when users had lots of windows open.
Thanks for the help,
Harold