Custom icons + MouseUp fix

[Harold L Hunt II]

Earle,

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