It appears from tests that I have been doing that a WM_MOUSEMOVE event occurs if the mouse is stationary over a window and the window is made to move when a SetWindowPos is issued to that window.

If this, in fact, this is the case, is there any way to suppress the WM_MOUSEMOVE resulting from this or otherwise filter it?
Posted on 2004-01-17 21:30:49 by msmith
I guess that while you are doing the SetWindowPos you could redirect the mouse to another window with SetCapture then ReleaseCapture when you are done.
Posted on 2004-01-18 01:25:42 by donkey
Hi Donkey,

The example I gave was to simplify the question.

What I am trying to do is to move the control by moving the mouse and then move the control to follow it.

It works except that it seems that when the control moves, it causes a spurious WM_MOUSEMOVE because the mouse has "moved" relative to its previous position within the control.

When WM_LBUTTONDOWN occurs, I set a flag. When the flag is set, the control will try to track the mouse movement (until I receive a WM_LBUTTONUP).

I am displaying all relavant x and y coordinates, and I can see them oscillate because of the condition I describe. I need a way throw away WM_MOUSEMOVE unless it is actually caused by the mouse moving.
Posted on 2004-01-18 01:35:55 by msmith
Hi msmith,

Will have to do some tests to find out what is happening because though I understand the problem, I am having trouble visualizing the context. I am assuming that you are working on your dialog editor correct ? I will try a few things here but I know of no way to temporarily turn off mouse input other than redirecting it using SetCapture.
Posted on 2004-01-18 01:45:57 by donkey

This is how I normally "eat" messages:

.While TRUE
.Break .If !EAX

I hope it helps,

Posted on 2004-01-18 03:18:17 by akyprian
Hi Donkey and akyprian,

Donkey, you guessed right. And the shame of it all is that were it not for the spurious mousemove events, it would work great.

akyprian, I don't want to get rid of all mousemove events, just the ones that occur from the window moving (not the mouse).

I am looking at several ideas. One is to calculate the relative xy that will occur from the window moving and test for these values. If they match, I will exit the routine doing nothing.

Remember, I used the word oscillation, not as a figure of speach, but rather as an observed fact. When the undesired mousemove events occur, my code issues a new (undesired) SetWindowPos which in turn causes a undesired movement...

Is there any way to get the mouse position (relative to the parent window, not the child) besides GetMouseMovePointsEx?
Posted on 2004-01-18 11:29:16 by msmith
Hi msmith,

I generally take mouse coordinates using the GetCursorPos function and then map it to the window I want using ScreenToClient or MapWindowPoints (for multiple points). I find it easier to deal with absolute coordinates but I am not sure it will make a difference in your case.
Posted on 2004-01-18 11:40:58 by donkey
I am considering using your suggestion of GetCursorPos. It appears to me that it gives the cursor position relative to the origin of the screen.

My idea is to capture the screen position of the cursor, the mouse position within the control, and the starting position of the control on the WM_LBUTTONDOWN event.

I will then calculate the offset of the mouse x and y to the x and y position of the control and save these.

When I get a WM_MOUSEMOVE event, I will resample GetCursorPos and then move the control in a way to maintain the previously saved offset from the new "screen position".
Posted on 2004-01-18 15:39:56 by msmith
Hi msmith,

I see what you mean now, I am working on an update to my package and doing some work on the selection rectangle drag and I see the extra mouse messages. It does not affect my purposes but I can see where yours would be. I am using absolute (screen) coordinates remapped with MapWindowPoints and OffsetRect (my own internal version to reduce API calling overhead) to position the graphic. I find that not using absolute coordinates tends to add another level of complexity more than it removes them, for example I can map to any child directly from the screen position but using the parent coordinates I must first convert to absolute then remap for some functions. Also there are many API functions, some that I use, that require absolute coordinates.
Posted on 2004-01-18 16:45:21 by donkey
Hi Donkey,

Its working pretty well now.

I'm not using ScreenToClient yet, so it needs a different y correction factor on 98 than on XP. I think this is because XP has a thicker title bar than 98.

I'm hoping that using ScreenToClient in my offset calculations will fix this.

The only other thing is that it is possible to "outrun" the control with the mouse. Can SetCapture fix this?
Posted on 2004-01-18 18:01:04 by msmith
I am not sure what you mean by "outrun". If you mean that the mouse runs over the edge of the window and you no longer recieve the messages (they are being sent to another window) then the only thing I can suggest is SetCapture. I had problems with this in the Toolbar Menu sample I wrote (available on my website) and ended up having to use a separate DLL and a Message Hook to relay the messages properly to the menu. However it is highly unlikely that this is your problem because with menus you do not have control of the message loop and that was where my problems started. You may try a simple local mouse hook, it could solve all of the problems.
Posted on 2004-01-18 18:08:55 by donkey
Hi Donkey,

I just added SetCapture on mouse down and release capture on mouse up and it works perfectly.

I'm taking a break for dinner and will try the ScreenToClient thing later to see if it fixes the 98/XP problem.

As always, many thanks!

I have been working on a project at work for the last 5 weeks, so not much has been done on the compiler during that time at all. I haven't forgot about getting you a beta copy, but I would like to add a few things first (like a dialog editor).
Posted on 2004-01-18 18:16:05 by msmith