Bug 183292

Summary: Consuming a mouse release event in a figure's MouseListener has no effect
Product: [Tools] GEF Reporter: Tom Crockett <Thomas.M.Crockett>
Component: GEF-Legacy Draw2dAssignee: gef-inbox <gef-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: heiko.boettger, nyssen
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Tom Crockett CLA 2007-04-19 17:52:49 EDT 
SWTEventDispatcher.dispatchMouseReleased() looks like this:

public void dispatchMouseReleased(org.eclipse.swt.events.MouseEvent me) {
	receive(me);
	if (mouseTarget != null) {
		mouseTarget.handleMouseReleased(currentEvent);
	}
	releaseCapture();
	receive(me);
}

Because of that call to releaseCapture(), it doesn't matter if you call consume() on the event inside handleMouseReleased. In the GEF subclass, DomainEventDispatcher, it looks like this:

public void dispatchMouseReleased(org.eclipse.swt.events.MouseEvent me) {
	if (!editorCaptured) {
>		super.dispatchMouseReleased(me);
>		if (draw2dBusy())
>			return;
	}
	if (okToDispatch()) {
		setRouteEventsToEditor(false);
		domain.mouseUp(me, viewer);
		updateFigureUnderCursor(me);
	}
}

draw2dBusy() never returns true after a mouse release, so the method will always continue and get propagated to the GraphicalEditor. If I have a figure on top of the graphical editor which is supposed to intercept all events, I don't want that to happen.
Comment 1 Eclipse Webmaster CLA 2007-07-29 09:22:26 EDT 
Changing OS from Mac OS to Mac OS X as per bug 185991
Comment 2 Alexander Nyßen CLA 2011-03-10 12:51:49 EST 
Bug #242909 seems to be closely related to this. I think it will make sense to investigate both together.