Community
Participate
Working Groups
1- select a connector and its label (a child of the connector) 2- Click on the label to drag the group 3- NullPointerException in DragEditPartsTracker DragEditPartsTrackerEx(DragEditPartsTracker).updateTargetRequest() line: 577 The basic problem is that in the method captureSourceDimensions() the operatorSet was empty because the logic there excludes all the dependent editparts (the label) which leaves the connector which does not understand the request. Having an empty operation set will cause the code that initializes the 'compoundSrcRect' field to not be invoked in the same method. Then latter in the updateTargetRequest, there is no assumption that the variable can be null and you get the exception.
What do you want to happen? Do you think the label should be draggable in this case, or do you just want a NOT sign without the NPE?
The same error happens when there is an extension of NonResizableEditPolicy installed on a part where isDragAllowed is set to false. When attempting to drag said part, DragEditPartsTracker.captureSourceDimensions creates an operation set which ends up being empty since the part doesn't understand the request. As a result, compoundSrcRect and sourceRectangle are both null when it leaves the loop. I noted there was a TODO under this loop for Pratik to check if the operation set ever does not include the source edit part, and there is code to make sure the sourceRectangle is not null (this is a case where it is). However, compoundSrcRect may still be null, and that is not taken care of... What should happen is that perhaps DragEditPartsTracker.handleDragInProgress could check if the operation set is empty, and if so, do nothing? The result should be that if the operation set ends up empty, a NOT sign without the NPE would be the best result.
As a side note, a workaround (for some cases) until this bug is fixed is to just override getDragTracker for problematic edit parts: public DragTracker getDragTracker (Request req) { return new SelectEditPartTracker(this); } Note - this "workaround" is overly simplified, but the basic idea should work - if a part is not supposed to be dragged, return a different tracker when asked.
The problem mentioned in comment 2 was fixed in 3.1.1. See bug 106114.
The fix for bug 106114 should be propogated to 3.2
The fix for 106114 is already in the 3.2 stream. Resolving as duplicate... *** This bug has been marked as a duplicate of 106114 ***
