Why does move-dragging methods not change cursor?

I couldn't remember how to move methods with the mouse...

Its different than the normal MS-Windows convention (which is a bit of a
nuisance - although I imagine the thought process is that you copy more than
you move - so default to copy on straight drag instead of the MS - drag is
move).

So - I tried Ctrl, Shift, Alt - but the mouse cursor always stayed the
same - so it wasn't clear to me what it was going to do?

Eventually I used the help - and searhing on Drag did give me the answer
(hurrah for the help) - however, Why doesn't the mouse curser change to a
non (+) cursor when I use (to me rather confusingly) - Shift-Drag.

I guess this is a feature request - I don't think its hard to change the
cursor. Also - for Alt-Drag a cursor with a (-) might be helpful too.

Tim,

> I couldn't remember how to move methods with the mouse...
>
> Its different than the normal MS-Windows convention (which is a bit
> of a nuisance - although I imagine the thought process is that you
> copy more than you move - so default to copy on straight drag instead
> of the MS - drag is move).

The MS guidelines allow you to choose a sensible default operation
which is what we have done. The Shift modifier key then inverts that
operation. It's not so much that it is the more common operation but,
rather, that it is safer. Moving methods from an existing class to a
new one by accident is liable to break the image.
 
Erm... well on my box the cursor does change:
- no modifier = move
- + sign = copy
- arrow sign = remove

Is there something strange about your Windows version or your image?

Best regards

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy Bower wrote:
> Tim wrote:
>>So - I tried Ctrl, Shift, Alt - but the mouse cursor always stayed
>>the same - so it wasn't clear to me what it was going to do?
>
> Erm... well on my box the cursor does change:

Okay, you're both right. ;-)

The cursor only changes after the mouse moves following a change in
Shift, etc. This has been something that's bugged me for some time,
though I've learned to just live with it.

Consider this a bug report / enhancement request to make the drag cursor
change immediately as a modifier key is pressed/released.

--
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Yes - I finally figured this out as well. I never understood it becuase I
guess my use-case is different. I start dragging, get to my destination and
then panic... what do I really want to do (and of course my mouse is not
moving at this point), do I want to move, copy etc?

In native windows, pressing the different keys changes the cursor, in Dophin
not... of course I can imagine that its easier to code when the mouse is
moving, check the keys status... vs. a callback becuase keystate has
changed.

Now I now, I will wiggle the mouse, but it its not obvious until you know
how, so add it to the cosmetic enhancments list.

Tim

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...

Andy, Blair -- Is this a worthwhile change to make?

Bill Dargel wrote:
--
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
Yes, I think so and had recorded it as #2040, but forgot to say so.

FWIW though, its not a terribly trivial thing to do properly. The problem is
that the drag source may not have focus during the drag operation (if the
first click on a window is to initiate a drag, focus will not be set), and
therefore the MouseTracker may not see the key presses. Where the drag
source does have focus it is easy enough, and maybe it is worth doing just
for that case in the interim.

Regards

Blair

Blair McGlashan wrote:
> FWIW though, its not a terribly trivial thing to do properly. The problem is
> that the drag source may not have focus during the drag operation (if the
> first click on a window is to initiate a drag, focus will not be set), and
> therefore the MouseTracker may not see the key presses. Where the drag
> source does have focus it is easy enough, and maybe it is worth doing just
> for that case in the interim.

Seems the interim solution might be worth it.

Is there anything wrong with forcing the setFocus at the start of a drag
operation (if that would make the more complete solution easier)?

BTW, I presume that the more complete solution will include being able
to cancel a drag using the 'Esc' key. Right now it only works if the
source had focus at the start of the drag.

--
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
Well that would be one way, but it would be non-standard. If you test out
the Windows explorer you will see that it does not do that, although some
other applications do, including Microsoft ones such as Outlook Express.

>
> BTW, I presume that the more complete solution will include being able to
> cancel a drag using the 'Esc' key. Right now it only works if the source
> had focus at the start of the drag.
>

Yes, that could be sorted at the same time since it is essentially the same
issue.

Regards

Blair

Blair McGlashan wrote:

> Yes, I think so and had recorded it as #2040, but forgot to say so.

Incidentally, another issue that feels (from a user's POV) very similar, even
though the underlying issue may not be the same, is as follows.

    In the CHB change a method's text (don't save).
    Select another method in the method list.
    Type N to agree that you do want to discard the changes.

The displayed method is not changed to the newly selected one; it seems to
require a mouse move or similar before the change is visible (D5 and D6 -- and
D4, come to that ;-).

It has always irritated me a little...

    -- chris