Unless I am going nuts I think something has changed recently with the navigator… and not for the better
Typically I will create a class and add some methods… Then when I want to generalize (or make a method privately available to other classes in a module) I will create a interface and then Drag the relevant methods and drop them on the interface.
What I think used to happen is that the method definition (without code) was added to the interface and stayed in the original method as one would expect…
What seems to be happening in 3.1 is that the method signature and return type is added to the interface but then the original method is deleted from the class. It took me a awhile to figure out how the method was being deleted from the class… I thought I was going out of my mind!!!
I can get it to work as expected if I hold down the option key during a drag… but there is no situation I can think of where one would want a method deleted from the class, when dropping it on an interface to add it’s signature to the interface!!!
Either dropping a method without the alt key on an interface should not be allowed, or it should just add it to the interface and NOT removed from the class as it did before.
Obviously I think the latter is the most user friendly behavior as the context obviously shows the user’s intension even if they don’t hold down the alt key!!! And of course that was how it used to work.
Slavish adherence to UI guidelines is nice in a an academic sense but not always practical… It should be as forgiving as possible.
I think this new behavior with interfaces is a bug… but was it an intensional change on Xojo’s part or an oversight?
The navigator is annoying as it is, please don’t make it more so!
Drag & drop is a move by default
Holding the option key makes it a “copy”
Thats very standard behavior
FYI - the IDE does this in 2014r3, 2014r2.1, 2014r2, 2014r1.1, 2014r1, 2013r4.1, 2013r2 (basically every version of Xojo)
This drag & drop wasn’t possible in previous versions - the best you could do was copy paste
[quote=154926:@Norman Palardy]Drag & drop is a move by default
Holding the option key makes it a “copy”
Thats very standard behavior
[/quote]
Except that a move drop makes no sense when doing it from a class method to an interface as you are NOT copying the method, but only its signature, my point stands…
Supporting a nonsensical operation that can result in accidential CODE LOSS (thanks goodness I had not saved) if someone forgets to push the alt key is NOT a good thing. Normally if you move something accidentally the code is not destroyed… here it is…
And because of that I don’t see how teh operation is really a move without the alt key as teh whole method is not moved.
And because the code does not go along, with the alt key it it’s not a true copy either.
This is one of those things that do not neatly fit the standard UI conventions.
Either dropping a method on an interface without the alt key should not allowed (and ideally popup an error message as to why) or in the name of user friendliness it just copies the signature . As I said the operation is not really a move OR a copy.
Right now it is too easy to lose code accidentally … (yes i know Version control… but that is not the point)
[quote]FYI - the IDE does this in 2014r3, 2014r2.1, 2014r2, 2014r1.1, 2014r1, 2013r4.1, 2013r2 (basically every version of Xojo)
This drag & drop wasn’t possible in previous versions - the best you could do was copy paste[/quote]
I guess I am mis-remembering … I must have been doing copy and paste … BTW did drag and drop with interfaces work in RS?
Drag with option is copy - for controls methods events properties etc.
Drag without option is move - for controls methods events properties etc.
And in many other apps those are adhered to.
Not following that convention would be VERY surprising.
And sometimes following it and sometimes not would be worse.
There’s always undo when you realize you’ve moved something you meant to copy.
And no you could not do anything like this in RS except maybe by copy paste and the code was stripped there too since interfaces do not hold code.
[quote=154935:@Norman Palardy]Drag with option is copy - for controls methods events properties etc.
Drag without option is move - for controls methods events properties etc.
And in many other apps those are adhered to.
Not following that convention would be VERY surprising.
[/quote]
Not in this specific case.
The point is this situation is nether fish nor fowl. As i said it’s not a true move or copy either way because of code loss. When you have a unique situation the UI should adapt to it.
[quote]And sometimes following it and sometimes not would be worse.
[/quote]
Then in this case Drop Move should not be allowed since it results in code loss. Best to be conservative about that possibility and disallowing drops contextually are even part of the Xojo framework… First principle should be do no harm… or is that for doctors…
Still, as I said IMO it it would be better to just copy the signature as that is the only sensible thing the user could be doing… and if not, no real harm is done.
That depends on WHEN you realize it… and we really should not be put into that situation for an operation it is easy to do inadvertently!!!
Anyway I doubt I will convince you…
If I do submit an bug report (or feature request) on this, please let someone else think about it before closing it.
[quote=154938:@Karen Atkocius]Not in this specific case.
The point is this situation is nether fish nor fowl. As i said it’s not a true move or copy either way because of code loss. When you have a unique situation the UI should adapt to it.
[/quote]
No one would remember that 99% of the time its like this but this once case is unique.
Thats why there are UI guidelines - so people can expect the same kind of behavior everywhere an the same sets of mouse drag + modifiers do the same things.
The code loss means the behavior is NOT the same as any other drag operation . That is a VERY basic difference. I would have hoped that you would have at least acknowledged that.
In any case disallowing a drop move contextually would not be against guidelines…Heck OSes have support for that built in as well as does the Xojo framework.
IMO this is a case of the tail wagging the dog. Well as i said not much point going round and round on this…
Why not just add the signature whether or not the option key is pressed and leave the original alone? Most operating systems have two different results for the same operation…
If you drag a file/folder to another folder it moves it, hold the alt key down and it copies, but if you drop it on a different drive, it copies it instead of moving and you need to use the modifier key to move it instead…
@Norman,
if the code of the function is not copied or moved too than it is not the standard behaviour of a copy or move task. So please don’t rely on that factor and call it a bug.
The expected behaviour when dragging a function to an interface ist to create an Interface from the function (without deleting the original function) and nothing else.
The expected behavior when dragginganything is that you’re moving it. This is a general convention of desktop computing. Whether you’re in Xojo, or in Finder. Dragging things moves them (thereby “deleting” them from the original location.)
[quote=155091:@Torsten Gaidies]@Norman,
if the code of the function is not copied or moved too than it is not the standard behaviour of a copy or move task. So please don’t rely on that factor and call it a bug.
The expected behaviour when dragging a function to an interface ist to create an Interface from the function (without deleting the original function) and nothing else.[/quote]
Interfaces by definition don’t have any code so if you “move” the method there it HAS to drop the code
Now I’d be fine with NOT accepting the move of a method and then you have to COPY it to an interface
That’s probably a reasonable way to deal with this
But you can’t move a method to an interface. They are not the same type of thing. Throwing away the code is not moving it…
I think we should all be able to agree a lossy operation like that, which had about 0 chance of being the user’s intension is not a good thing…
The next thing to look at IMO is what is most efficient/convenient behavior FOR THE USER which does not cause loss of code.
Copying the signature and leaving the method in place meets those criteria more than disallowing the drop altogether…
Yes an academic argument can be made that the option key should be used… but people are human and in this specific case not needing the option key to do this can be logically justified.
As I said it’s hard to imagine a user dropping a method on interface with the intention of deleting the method code… So what harm is done by supporting the intended action with or without the option key? I really don’t think it would confuse anybody… it’s the little things like this that help the IDE be more user friendly.
That said, if just copying the signature without the option key is not going to be allowed, then then that type of drop should be disallowed because of the potential for unintentional code lose.
Tim, I agree with that, when the hole object is moved/copied, because that is the behaviour of dragging objects.
In the other case I would prefer, when dragging a function/method to an interface, that an interface of this function is created.
So that this dragging feature is driven by context. Why should these technique only be used for context menus?
I really like context driven user interfaces, that help me or my customers to quickly and easy solve the problem/task they are currently working on.
[quote=154939:@Norman Palardy]No one would remember that 99% of the time its like this but this once case is unique.
[/quote]
Actually Norm, I just realized it is NOT a unique case.
I had a timer subclass in the navigator… I was just trying to reorder things in teh navigator and i accidentally dropped it on a Window in the navigator tree (not on teh window layout … I did not have the option key pressed yet it added the control to the window and left subclass definition in place.
How is that significantly different from dropping a method on an interface, copying it’s signature to teh interface and saving the method where it is?
[quote=155943:@Karen Atkocius]How is that significantly different from dropping a method on an interface, copying it’s signature to teh interface and saving the method where it is?
[/quote]
That should have read:
How is that significantly different from dropping a method on an interface, adding it’s signature to the interface and leaving the method where it is?
