Community
Participate
Working Groups
According to the documentation for "EditPartViewer.findObjectAtExcluding(location, exclusionSet)", the exclusionSet parameter is a set of EditParts to be excluded from the search. However, the implementation of this method in GraphicalViewerImpl uses the ExclusionSearch class which incorrectly tests the exclusionSet collection for the presence of IFigures instead of EditParts. The implementation of this method in TreeViewer correctly tests the exclusionSet parameter against EditParts.
You are right, this is indeed inconsistent. GraphicalViewerImpl should test for EditParts as well. There is GEF code depending on the current functionality, which could be changed quite easily: ConnectionEndpointTracker and DragEditPartsTracker (indirectly via TargetingTool#getExclusionSet()) seem to be the only GEF clients that pass in figures to be excluded from the search. However, there may be third-party code that depends on the current implementation. So we will at least have to announce the change.
*** Bug 348358 has been marked as a duplicate of this bug. ***
What will have to be investigated in terms of client code are subclasses of TargetingTool, overwriting getExlusionSet(), as well as subclasses of AbstractTransferDropTargetListener, overwriting getExlusionSet() there. All other implementations seem to pass in an empty collection.
(In reply to comment #3) > What will have to be investigated in terms of client code are subclasses of > TargetingTool, overwriting getExlusionSet(), as well as subclasses of > AbstractTransferDropTargetListener, overwriting getExlusionSet() there. All > other implementations seem to pass in an empty collection. AbstractTransferDropTargetListener will be no problem, as the only subclass overwriting getExclusionSet() returns a list of edit parts, which is the correct contract.
(In reply to comment #4) > (In reply to comment #3) > > What will have to be investigated in terms of client code are subclasses of > > TargetingTool, overwriting getExlusionSet(), as well as subclasses of > > AbstractTransferDropTargetListener, overwriting getExlusionSet() there. All > > other implementations seem to pass in an empty collection. > > AbstractTransferDropTargetListener will be no problem, as the only subclass > overwriting getExclusionSet() returns a list of edit parts, which is the > correct contract. Regarding the subclasses of TargetingTool, the implementation within ConnectionEndpointTracker may be easily migrated to provide a list of edit parts rather than their figures, while the other overwriting subclass, i.e. DragEditPartsTracker is a bit more problematic, as it puts the connection layer into the exclusion set.
Created attachment 212504 [details] Patch with proposed changes I have create a patch that demonstrates how the current implementations could be adopted to restore the EditPartViewer#findObjectAtExcluding contract within GrahicalViewerImpl and its clients. I have the fear that restoring the contract will have to be paid with a decrease in performance (because the implementation within DragEditPartsTracker has to be adopted to traverse all edit parts with figures in the connection layer; at least this is how I currently see it), so I have not changed the code base yet but uploaded it as a patch for review.
Unassigning this and removing target milestone. This will not make it into 3.8.0, as we are past RC1 now.
