RE: [gef-dev] Selection assumption

[<David.Dubrow@xxxxxxxxx>]

Ok. Thanks. I'll ensure that I never create a selection that contains
both graphical and tree edit parts. This should be ok since the outline
(when open) always represents a superset of objects in the graphical
viewers.


-----Original Message-----
From: gef-dev-bounces@xxxxxxxxxxx [mailto:gef-dev-bounces@xxxxxxxxxxx] 
Sent: Friday, May 18, 2007 2:46 PM
To: gef-dev@xxxxxxxxxxx
Subject: RE: [gef-dev] Selection assumption

Yes. I actually have 3 viewers, 2 graphical ones plus the tree viewer in
the outline (which may or may not be open). Not all model objects have a
graphical viewer representation, but I always favor putting graphical
parts in the selection over tree parts. I didn't realize that there was
an assumption that selections would only contain parts from a single
viewer. I have not found that to be a problem except in the case of
these actions.



-----Original Message-----
From: gef-dev-bounces@xxxxxxxxxxx [mailto:gef-dev-bounces@xxxxxxxxxxx]
On Behalf Of ext Randy Hudson
Sent: Friday, May 18, 2007 2:38 PM
To: GEF development
Subject: RE: [gef-dev] Selection assumption

Are you saying that you have a structured selection consisting of
editparts from more than one type of viewer?



 

             <David.Dubrow@nok

             ia.com>

             Sent by:
To 
             gef-dev-bounces@e         <gef-dev@xxxxxxxxxxx>

             clipse.org
cc 
 

 
Subject 
             05/18/2007 03:23          RE: [gef-dev] Selection
assumption  
             PM

 

 

             Please respond to

              GEF development

             <gef-dev@eclipse.

                   org>

 

 





Hi Randy,

It's in the calculation of the enabled state that the ClassCastException
occurs. The action is not running.
In AlignmentAction#getOperationSet() only checks the first item in the
selection before passing on the rest of the selected parts to
ToolUtilities#getSelectionWithoutDependants() which directly casts all
objects to GraphicalEditPart.
MatchSizeAction#createMatchSizeCommand() calls
MatchSizeAction#getPrimarySelectionEditPart() which also does this. At
least, with the MatchSizeActions, I can override
SelectionAction#getSelectedObjects() and do the right thing, but with
AlignmentAction being final, I can't.

--David


-----Original Message-----
From: gef-dev-bounces@xxxxxxxxxxx [mailto:gef-dev-bounces@xxxxxxxxxxx]
On Behalf Of ext Randy Hudson
Sent: Friday, May 18, 2007 2:09 PM
To: GEF development
Subject: Re: [gef-dev] Selection assumption

The action correctly identifies that it should not be enabled in those
cases, so it should be impossible to get to run().

-Randy





             <David.Dubrow@nok

             ia.com>

             Sent by:
To
             gef-dev-bounces@e         <gef-dev@xxxxxxxxxxx>

             clipse.org
cc



Subject
             05/18/2007 10:18          [gef-dev] Selection assumption

             AM





             Please respond to

              GEF development

             <gef-dev@eclipse.

                   org>









Hi,

It seems that the MatchSizeAction actions and AlignmentAction make the
assumption that the selection they get will only contain
GraphicalEditPart objects. This assumption takes the form of cast
without checking the type first.
However, our application allows for objects that may be in the outline
only and not in the graphical viewer, and while these objects should
rightly be allowed to exist in the selection, in order to allow
non-graphical actions such as cut, copy and paste to access them, they
cause ClassCastExceptions when the graphical actions access them.

I can override them MatchSizeAction actions' getSelectedObjects()
method, but am afraid that AlignmentAction is final so I can't do so for
that action. However, it seems that these actions should check before
casting the selected EditPart objects.

Should I submit a bugzilla? With a patch?

Thanks!

David.Dubrow@xxxxxxxxx
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev


_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev


_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev