Bugzilla – Full Text Bug Listing
| Summary: | findObjectAtExcluding doesn't exclude | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Michael Baehr <codex69> |
| Component: | GEF-Legacy GEF (MVC) | Assignee: | gef-inbox <gef-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ahunter.eclipse, hudsonr |
| Version: | 3.3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
I think one problem here is that there is not consistency in what is in the Collection. According to the javadoc, the collection contains editparts, but according to its usage in GEF and the ConditionalTreeSearch implementation, the editpart's figure(s) must be passed in instead. Can you workaround this inconsistency by passing in the figures to be excluded instead of editparts? I don't think this can be changed safely for 3.4 at this point. Maybe the javadoc could be updated at least. I'm not sure if using figures in the collection would give trouble with the optional condition - the accept method finds the editpart for the figure and uses it for the condition ( condition.evaluate(editpart) ) I worked around the problem by subclassing the graphical viewer implementation (in my case ScrollingGraphicalViewer) and copying some code into the createGraphicalViewer() method of my editor to use my subclass instead of the original one. In my subclass I overwrite findObjectAtExcluding with the code in my first comment. It's a little bit of a hack, but it's working for me. (In reply to comment #2) > I'm not sure if using figures in the collection would give trouble with the > optional condition - the accept method finds the editpart for the figure and > uses it for the condition ( condition.evaluate(editpart) ) I think it would work. If you are calling: viewer.findObjectAtExcluding(pt, editparts, condition); You would just change to: + List partFigures = new ArrayList(); + for (GraphicalEditPart part : editparts) + partFigures.add(part.getFigure()); viewer.findObjectAtExcluding(pt, partFigures, condition); Maybe your concern was the accept method would walk back up the figure parent chain until it finds some editpart, and that might be the editpart you wanted to exclude intially. This shouldn't happen, because prune() would have stopped at the editpart's figure immediately and never tested (i.e. accept(...)) any figures contained inside. Would you be able to test the above by commenting out your overrides and inserting the 3 lines above? Seems to work! I'm not using the condition, though, so I can't comment on it working as expected. (In reply to comment #4) > Seems to work! [...] |
Build ID: M20080221-1800 Steps To Reproduce: 1.Calling findObjectAtExcluding will always return the same EditPart, even if it is in the collection of to be excluded EditParts More information: findObjectAtExcluding uses an inner class ConditionalTreeSearch (that extends ExclusionSearch). The overwritten method accept doesn't check if the found editpart is in the exclusion connection, but instead relies on the superclass ExclusionSearch for that. ExclusionSearch checks IFigures against the collection (which contains EditParts) and therefore never excludes anything. Adding the exclusion test in the overwritten accept method solves the problem: class ConditionalTreeSearch extends ExclusionSearch { private Collection coll; ConditionalTreeSearch(Collection coll) { super(coll); this.coll = coll; } public boolean accept(IFigure figure) { EditPart editpart = null; while (editpart == null && figure != null) { editpart = (EditPart) getVisualPartMap().get(figure); figure = figure.getParent(); } return editpart != null && (!coll.contains(editpart)) && (condition == null || condition.evaluate(editpart)); } } If ExclusionSearch would allow access to the collection (e.g. make it protected), ConditionalTreeSearch wouldn't need to save an own copy.