| Summary: | Small bug in funciton findObjectAtExcluding of GraphicalViewer | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Mateu <the_hommer_83> |
| Component: | GEF-Legacy GEF (MVC) | Assignee: | gef-inbox <gef-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
A MoveHandle does not overlap the editpart, therefore the editpart is not below the move handle. Why would you need a handle to say that it is part of the editpart? |
In GraphicalViewer the function "public EditPart findObjectAtExcluding(Point pt, Collection exclude,final Conditional condition)" contains a bug: When a figure is selected with the selectionTool, a MoveHandle is created which sorrounds the selectedFigure. When the mouse is on top of the MoveHandle the funciton findObjectAtExcluding(Point pt, Collection exclude,final Conditional condition) returns the rootEditPart instead of the figure wich contains the MoveHandle. This is because this funciton uses IFigure figure = getLightweightSystem().getRootFigure().findFigureAt(pt.x, pt.y, new ConditionalTreeSearch(exclude)); to find the figure and then finds the editPart. I have solved this problem by adding the following code: if (figure instanceof MyMoveHandle) { IFigure searchFigure = ((MyMoveHandle) figure).getOwner().getFigure(); figure = searchFigure.findFigureAt(pt.x - 1, pt.y - 1); } Where MyMoveHandle is an extendion of MoveHandle with the method getOwner setted to public.