Quote:Original post by EasilyConfused
The default Windows behaviour is that the cursor keeps moving, even if the window is at its minimum or maximum size, but no longer stretches or shrinks the window.

I'd say this is the more desired behaviour. It is very rare that manually changing the cursor position improves user experience. Consistency is the most important thing in interfaces so I'd always suggest mimicking the way the OS behaves where possible.

Quote:Original post by ApochPiQ
Sounds like a job for ClipCursor.

Quote:Original post by lordikon

Quote:Original post by kittycat768

Mmm... for me it's kind of the opposite. I don't confine the cursor to a rectangle. I try to keep it out of the rectangle that defines the window's minimum size. One major problem I'm running into is that the WM_SIZING message is getting called a bajillion times per second so when my window reaches it's minimum size the cursor sort of become trapped until I move the cursor a lot in one motion. I'm going to try to implement a timer in order to slow this down. If I can't slow it down I'm going to remove the code that limits the window's size. If the user wants a window that's 123 pixels by like 20 pixels, more power to them.

kittycat768 casts Xfer on ApochPiQ's Lobo avatar. ApochPiQ's Lobo avatar dies.

Edit: Acutally, I removed the "p.x = rcWnd.left" and "p.x = rcWnd.right" from my corner sections. It was an unnecessary bit of code that was causing the trapped cursor.

I thought about enforcing the cursor position at the time the subsequent message that is called after WM_SIZING, which I believe is WM_WINDOWPOSCHANGED or something similar. But I would have to store which window size the cursor was on and then calculate where to snap the cursor.

Quote:Original post by lordikon
I haven't gotten around to messing with the cursor much. My first attempt a couple of days ago I got the cursor within about 1 pixel of where I needed it most of the time, but if I altered the position during the WM_SIZING message it would cause the cursor to move by about 1 pixel each time WM_SIZING would be called, which caused the window to move erratically.

So my thought was to not try and move the cursor during the sizing itself, but rather to let the sizing message finish, which would cause the window to resize, and then on whatever message came next I could then calculate where to place the cursor. However, once I get to the next message I would no longer have information about which corner/side the cursor was moving because that info is within WM_SIZING, so I'd have to store that info during WM_SIZING to use later.

GetCursorPos(&p);rcWnd -> left = p.x;rcWnd -> top  = p.y// Do stuffp.y = rcWnd -> top; // Update p.y because the top edge was scaled to fit the aspect ratioSetCursorPos(p.x, p.y);

Quote:Original post by lordikon
I was snapping it to the corner, or at least I thought so. I've honestly only spent a little time on the mouse cursor issue among other things, chances are my calculations may be off by 1 pixel or so somewhere and it might be causing the strange behavior.

This is a work project, and I just got moved to another system so I may not get to solve the cursor issue for a little while.