Bug 101558 - [Tool] Inconsistent post-execute selection between CreationTool and ConnectionCreationTool
Summary: [Tool] Inconsistent post-execute selection between CreationTool and Connectio...
Status: NEW
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy GEF (MVC) (show other bugs)
Version: 3.0   Edit
Hardware: PC All
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-23 17:00 EDT by Ed Willink CLA
Modified: 2010-11-04 06:36 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2005-06-23 17:00:14 EDT
In CreationTool performAction invokes selectAddedObject() so that the
newly created object is selected.

ConnectionCreationTool has no equivalent behaviour.

So in e.g. EDiagram new nodes are selected, but new links are not.

Copying the CreationTool code to ConnectionTool works fine.
? should it move up the hierarchy or just be copied?
Comment 1 Ed Willink CLA 2005-06-26 14:26:00 EDT
Related problems arise with a Redo of a Create or an Undo of a Delete not 
selecting the re-created part.

I seem to need an addSelectedObjectsWhenDone/Undone method in (derived)
commands to be able to find out what is available to select from an 
Undo/RedoAction. (Ok, it is solvable with instanceof and a get.)

I also note that the calculateEnabled method in DeleteAction is rather costly
in EDiagram where only transient links are not-deletable, so creating a
delete command and its delegate just on the off chance that a selection might
get deleted seems unnecessary. A canDelete() method in derived EditParts
saves the effort and works more consistently since run() always creates
a delete command anyway where it is sensitive to KEY_PERM_DELETE.

Comment 2 Randy Hudson CLA 2005-06-26 23:12:06 EDT
> I also note that the calculateEnabled method in DeleteAction is rather costly
> in EDiagram where only transient links are not-deletable, so creating a
> delete command and its delegate...

I don't know the example well, but the "delegate" should be created lazily on 
execute if there is any performance issue in the current implementation.