Mouse_no_longer_move

[krtxmrtz]

Krtx
re 4: release mouse button at (100,500) -- you'd like to see a 4-sided "drag cursor"
Not that it matters (since this is your app), but to my way of thinking, the cursor
"should" remain an up/dn arrow.
...

You're right, offhand I overlooked the fact that after mouse up the dragged on border has moved just to where the mouse now is. So, yes, it should remain up/down arrow. Sorry if I have misled you somewhat.

...
4-sided "drag=movement" arrow:
If you move cursor to a spot just inside of border, cursor is default arrow. If you then
mouse-dn, cursor is still default arrow. Only when you move the
mouse with the button down does cursor become 4-sided drag arrow....

Actually, I want the cursors to change already in the move event with mouse not yet down, for example like when you move it over objects in MS PowerPoint.

...
re 5: move mouse to (100,495) - cursor should become default arrow.

We agree that it should become default arrow. I assume that it is NOT
behaving that way. But, you are now "in" pic1, right?

So, wouldn't this be detected by [COLOR="blue"]pic1_MouseMove event, as in:

-- if cursor is up/dn arrow, change to default arrow
-- if cursor is default arrow, do nothing.

Spoo

The problem here is twofold:

1. After pic2's upper border has been dragged down, if the mouse button is released and then it is moved up we will be on pic1 and the latter's mouse_move event can indeed be used to restore the cursor to default. But if the mouse is moved too fast, pic1 may be skipped altogether and the first event to respond will be the form's (or some other neighbouring control's) mouse_move event. I'd like to avoid having to write mouse cursor restoring code for the mouse_move events of all the controls the mouse may be moved over.

2. Pic1 and pic2 are still the same size horizontally so, if the mouse is moved horizontally out of pic2 it will now be on the form or on some other control.