| GraphicalViewerImpl.findObjectAtExcluding() confusion [message #164317] |
Tue, 18 January 2005 11:48  |
Eclipse User |
|
|
|
I am attempting to make a targeting tool that simply changes the cursor
based on if the mouse is over an "isSelectable" EditPart or not.
The current wackyness that I'm dealing with is in
GraphicalViewerImpl.findObjectAtExcluding(). Specifically, the statements:
...
if (part == null)
return getContents();
...
After pruning my "root" EditPart by both the exclusion collection (which
isn't actually possible but I'm trying to make a point) AND the Conditional
it is *still* returned since it is the contents (i.e. retruned from
getContents()). Not only does this violate the exclusion contracts, it
prevents null from ever being returned (unless of course there are no
contents).
To add insult to injury, ScalableRootEditPart is selectable (i.e.
isSelectable() = true) so I have to explicitly exclude any RootEditPart in
my Conditional. This begs the questions: why would an internal EditPart
ever be returned to me and, perhaps more to my concerns, why are the
RootEditParts selectable?
I will open the appropriate defect reports if I am not crazy. Well,
actually, my sanity is orthogonal to the questions at hand.
--
Rob Grzywinski
|
|
|
| Re: GraphicalViewerImpl.findObjectAtExcluding() confusion [message #164369 is a reply to message #164317] |
Tue, 18 January 2005 13:36  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
>I am attempting to make a targeting tool that simply changes the cursor
>based on if the mouse is over an "isSelectable" EditPart or not.
> The current wackyness that I'm dealing with is in
> GraphicalViewerImpl.findObjectAtExcluding(). Specifically, the
> statements:
>
> ...
> if (part == null)
> return getContents();
This was done because on some platforms the mouse may be dragged out of the
viewer, or the mouse could be on top of the scrollbars. In both of these
cases null would be returned, but we wanted the contents instead. Probably
the tool (trackers and creation tool I think) should check for null and get
the contents itself, but we didn't do this at the time.
> After pruning my "root" EditPart by both the exclusion collection (which
> isn't actually possible but I'm trying to make a point) AND the
> Conditional it is *still* returned since it is the contents (i.e. retruned
> from getContents()). Not only does this violate the exclusion contracts,
> it prevents null from ever being returned (unless of course there are no
> contents).
>
> To add insult to injury, ScalableRootEditPart is selectable (i.e.
> isSelectable() = true) so I have to explicitly exclude any RootEditPart in
> my Conditional. This begs the questions: why would an internal EditPart
> ever be returned to me and, perhaps more to my concerns, why are the
> RootEditParts selectable?
Roots aren't internal. The root allows itself to be target by the selection
tool for the purpose of returning the MarqueeDragTracker. It will not get
selected because it doesn't return a drag tracker which selects it.
isSelectable() in this case means it responds to the drag tracker request.
> I will open the appropriate defect reports if I am not crazy. Well,
> actually, my sanity is orthogonal to the questions at hand.
|
|
|
| Re: GraphicalViewerImpl.findObjectAtExcluding() confusion [message #164392 is a reply to message #164369] |
Tue, 18 January 2005 14:15 |
| Eclipse User |
|
|
|
> This was done because on some platforms the mouse may be dragged out of
> the viewer, or the mouse could be on top of the scrollbars. In both of
> these cases null would be returned, but we wanted the contents instead.
> Probably the tool (trackers and creation tool I think) should check for
> null and get the contents itself, but we didn't do this at the time.
I really do hate to be a pain in the butt, but do you know how easy the
lives of developers would become if you simply put down the "why" (just as
you did right there) directly in the code?!? You clearly know the reason
when you write the code and I have to assume that you can type with some
expedience so there's little overhead in doing so. (It's my life's ambition
to understand and eventually overcome this fear, laziness, lack of training,
or whatever that makes software engineers neglect one of the most important
aspects of coding -- useful commenting!)
So the bottom line here is: are you going to update the contract so that it
reflects the code or the code so that it reflects to contract?
> Roots aren't internal. The root allows itself to be target by the
> selection tool for the purpose of returning the MarqueeDragTracker. It
> will not get selected because it doesn't return a drag tracker which
> selects it. isSelectable() in this case means it responds to the drag
> tracker request.
Well this is all well and good if you're using the default tools, but I am
not. At least I understand some of the "why"'s of what's going on so I can
change my code accordingly.
Thanks!
--
Rob Grzywinski
|
|
|
Powered by
FUDForum. Page generated in 0.25861 seconds
Home