I am chasing a bug that I suspect is my own misunderstanding about X:
TL;DR - Sometimes XEnterNotify events give global mouse coordinates that don't correspond to the window being entered.
I'm modifying a tiling window manager (ratpoison). The screen is divided into frames, each of which may contain a mapped window. If a frame contains no window, I'd like to focus the frame. So I ask for EnterNotify events on the root window, cast the XEvent to an XCrossingEvent, and then look at x_root and y_root to figure out where the mouse is on the screen. I expect to get the global screen coordinates. The problem is that sometimes when I move the mouse over the empty frame, I get an EnterNotify event on the root window, but the (x_root, y_root) members of the event give a point in the frame I came from (i.e., not at an exposed part of the root window).
Any suggestions?
I think the answer is the following:
The mouse coordinates are not guaranteed to be in sync with anything in particular. The only thing that seems really to be guaranteed is that the mouse was at one point at these coordinates and that a later event will have a later mouse position. In order to know the true mouse position, I either need to listen to motion events on the root window (so that I will eventually get the information I want) or else call (probably) XQueryPointer().
Note that I am not 100% certain of this answer.
Related
I'm using WM_MOUSEMOVE to get changes in mouse position. When simulating "knobs" for example it's desired to let the user go up/down with mouse without any limits. In this cases I hide cursor and use SetCursorPos to change its position every time user moves with it and detect just the difference from the original position.
Unfortunately it doesn't seem to work - if I set the mouse position, it sometimes works, but sometimes is one or more pixels away, which is just wrong. And even bigger trouble is that after the call another WM_MOUSEMOVE seems to be delivered, which unfortunately does the same thing as it wants to move the cursor back to the original position again. So it ends up in an infinite cycle or settings mouse position and receiving messages until the user releases the mouse button.
What's the correct approach or what's the problem?
The raw input system can do this - it lets you register for raw mouse input that isn't clipped or confined to the screen boundaries.
Broadly speaking, you register for raw input using RegisterRawInputDevices(). Your window will then receive WM_INPUT messages, which you process using the GetRawInputData() function.
See Using Raw Input for an example.
I hide cursor and use SetCursorPos to change its position every time user moves with it and detect just the difference from the original position.
This is just plain wrong. Instead, use SetCapture() to capture the mouse. All movements will be reported as WM_MOUSEMOVE messages with coordinates that are relative to the specified window, even if the mouse is outside of that window, until you release the capture.
Asking the user to move the mouse continuously, even after the cursor hit the screen limit is a very bad idea in terms of User Interface, IMHO.
Some games have another approach: when the mouse hit the "limit", the game enter a special mode: things appears to function exactly as if the mouse was moving, even if the user don't move it. When the user wants to exit that mode, he just has to move the mouse of the limit.
Doing so requires a timer, armed when the mouse hit some limit, executing code periodically as if the mouse was moving. The timer is stopped when a real mouse movement makes it leaves the limit.
Ok folks, so I found a solution simple enough:
The main problem is that SetCursorPos may not set the coordinates accurately, I guess it's because of some high resolution processing, nevertheless it's probably a bug. Anyway if SetCursorPos doesn't set the coordinates correctly (but +-1 in x and/or y) it also sends WM_MOUSEMOVE to the target window. As a result the window performs the exact same operation as before and this goes on and on.
So the solution is to remove all WM_MOUSEMOVE messages right after SetCursorPos:
MSG msg;
while (::PeekMessage(&msg, NULL, WM_MOUSEMOVE, WM_MOUSEMOVE, PM_REMOVE)) { };
Then retrieving the current mouse cursor pos using ::GetCursorPos .
It's ugly but seems to fix the problem. It basically seems that in some position of the mouse, the system always adds or subtracts 1 in either coordinate, so this way you let system do the weird stuff and use the new coordinates without trying to persuade system that your coordinates are the correct ones :).
I need obtain a MOUSE_DX and MOUSE_DY values where
MOUSE_DX is a difference between MOUSE_X and MOUSE_PREV_X
someone give stupid answer to my that i can hide cursor substract
succesive MOUSE_X between mouse move events, and when cursor
goes away from the centre of the sceen call ShowCursorPost to the
cantre of the screen - but this is a real hell : it is stupid perself also
calling ShowCursorPost generate fake mouse move events so
then I would need to filter out this fake movements then (It is hell)
Is there some more reasonable way of obtaining the MOUSE_DX
MOUSE_DY I need?
//EDIT (more explaining for questions )
I want to use mouse as a steering device - something like mowing yaw/pitch/roll of the camera
For this purpose I need to gest something like MOUSE_DELTA_X MOUSE_DELTA_Y
where such numbers are indeed the MOUSE_X-MOUSE_PREV_X where MOUSE_X/Y are
coordinates of the mouse cursor given to me by WM_MOUSEMOVE
allright - this works to some extent but not much:
I need the DX DY walues related to mouse movements but do not need
a mouse cursor at all, when mouse cursor hits the screen edge i will
not gest full DX but some cutted and then all zeros
To prevent this i call (as somebody advice me) SetCursorPos when
the cursor nears to the edge of the desktop (the window really becouse
I do not want him to exit my window) then I call SetCursorPos
to the centre of the client area (I also make cursor invisible, and
also clip it to the window size but it also brings a lot of
trouble, need to unclip the areo on alt+tab etc it is all tiresome
and it is all a complex workaround for such simple thing like obtaining
DX DY) I just do not need this f*cking invisible cursor moving on screen
at all here - but I need mouse DX DY only
but let assume that this machinery with invisible cursor is tiresomely
coded and debugged
the other trouble is that when I call SetCursorPos It also generates
fake mouse movement backward and it generates fake DX and DY then
(it is hard to filter - at least i do not know how to do it all
in a robust way)
(can this fake mouse move been easily filtered out?)
I did it all this invisible cursor clipping SetCursorPos and filtering
out the false DX DY but it is very ugly thing very error prone and
confusing - all this for simple obtaining (cursor independant/mouse
related)DX DY for every move - this is hell It made me a long hours to
debug this stuff so I am angry - this is coding hell - this is terribly
wrong so I am angry and need a good way of doing it
The WM_MOUSEMOVE event tells you the current position of the cursor. Well, it's actually the position of the cursor when the event was placed in the message queue, not quite the same thing. But the system does not keep track of the position of the cursor associated with the previous WM_MOUSEMOVE message. From this you can conclude that you will need to keep track of that.
So, do the following:
Declare variables to hold the previous cursor position.
Initialize those variables to the current cursor position.
Whenever you process WM_MOUSEMOVE you can compare the current position with the previous.
Once you have done that, update the previous cursor position to be equal to the current position, ready for the next WM_MOUSEMOVE message.
What you could try:
Use the ClipCursor function to confine the cursor inside your window, or a sub-rect.
When the mouse hit your "border", start a timer. Stop the timer when the mouse leaves the border.
On each timer tick, you could generate a fake DX or DY.
The idea is to have the behavior of many games: you move the mouse, hitting a border, and then all behave as if you were still moving the mouse.
I'm looking to simulate a kiosk mode for Safari on Windows. OSX will not work with my input hardware and Chrome's GPU acceleration is too slow for the machine I'm using.
The only plausible solution [so far] is to run Safari and send an F11 (fullscreen) keystroke, but prevent the URL bar from expanding when the mouse reaches the top pixels of the screen.
I've looked and can't seem to find any good solution and would like to know if I can restrict the cursor movement from reaching the top pixel of the screen?
If anyone has any other solutions, that would be great!
You can use the ClipCursor function to do this.
Confines the cursor to a rectangular area on the screen. If a subsequent cursor position (set by the SetCursorPos function or the mouse) lies outside the rectangle, the system automatically adjusts the position to keep the cursor inside the rectangular area.
You can poll the cursor position and correct it using a timer, but this is not ideal. You could also cover the top bar by a transparent topmost window. This way, input will never reach the top bar.
EDIT: If Internet explorer is an option you have the possibility to use the COM object to embed what you need in a custom application. Other browsers might have similar APIs, but I'm not familiar with them.
Whenever I write mouse handling code, the onmousedown/onmouseup/onmousemove model always seemed to force me to produce unnecessarily complex code that would still end up causing all sorts of UI bugs.
The main problem which I see even in major pieces of software these days is the "ghost mouse" event where you drag to outside the window and then let go. Once you return back into the window, the application still thinks you have the mouse down even though the button is up. This is especially annoying when you're trying to highlight something that goes to the border of the screen.
Is there a RIGHT way to write mouse code or is the entire model just flawed?
Ordinarily one captures the mouse events on mouse down so the mouse move and mouse up go through your code regardless of the caret moving out of you application window.
More recently this is a problem when running a VM or remote session, its difficult for apps in these to track the mouse outside of the machine screen area represented by a window on a host.
I'm not sure what environment you're attempting to track mouse buttons in, but the best way to handle this is to have a mouse listener that tracks onmouseup 100% of the time after you've detected onmousedown.
That way, it doesn't matter what screen region the user releases the mouse button in. It will reset no matter where it happens.
I'm working on a Win32 control. There could be hundreds of "items" on this control. Those are not windows, but internal objects (eg: rectangles). Depending on the mouse position I want to change the mouse cursor. That is fine, I can use WM_SETCURSOR.
At the same time based on mouse move I want to display a status bar which shows details about the object currently under the mouse. For that I can use WM_MOUSEMOVE.
Because there could be hundreds of items, traveling all of them to find one under the mouse, well it's not efficient, especially two times (one for set cursor, one for mouse move).
To make it short, do you know if WM_SETCURSOR and WM_MOUSEMOVE are ALWAYS in pair? In that case I can calculate what I want during WM_SETCURSOR. The other option would be to set the mouse cursor during WM_MOUSEMOVE, but as far as I know that it's not a good solution (will flicker).
Thanks
While they might currently always come as a matched pair, you probably can't rely on this behaviour.
You can set the cursor during WM_MOUSEMOVE (using SetCursor), and it won't flicker, as long as (IIRC), you return TRUE from WM_SETCURSOR without doing anything (i.e. you eat the message), and your window doesn't have a class cursor assigned to it.
You might also try GetMessagePos() (gives cursor screen coordinates), then MapWindowPoints() and see if it's in hot rectangle, or something similar.
Most important of all is that your window message handlers shouldn't worry about holding or calculating anything. You should simply signal your application's logic that the mouse is potentially over new area and make it find the object(s). Once you find the hot area (or more than one), cache its (their) boundaries and check the following mouse moves against those. Once the mouse moves out from one of them, you can rebuild your hot-object-list.
You don't have to be hunting for the hot area all over the control on every mouse move.
In case when there can be many objects sharing the same area, there's the question of z-order. Think about it when you're creating those objects and handle their movement.
Also you should think about an efficient data structure holding the object coordinates so you don't have to check every single object every time you're looking for the hot one.
Just my two euros. ;)
Is there any way to cache the last item that was found, and shortcut the lookup if the cursor is in the same place? That would be the most robust solution.