Community
Participate
Working Groups
Using the following snippet, public class Snippet { public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(); shell.setLayout(new FillLayout()); final Canvas canvas = new Canvas(shell, SWT.NONE); canvas.addListener(SWT.MouseExit, new Listener() { public void handleEvent(Event event) { System.out.println("Mouse exited: " + event); } }); canvas.addListener(SWT.MouseUp, new Listener() { public void handleEvent(Event event) { System.out.println("Mouse up: " + event); } }); shell.setSize(300, 300); shell.open(); while (!shell.isDisposed()) { while (!display.readAndDispatch()) { display.sleep(); } } } } when clicking into the canvas area and releasing the mouse outside the viewer, on Windows XP, the mouse up event is received before the mouse exit event, while on MacOSX Cocoa, the mouse exit event is received before the mouse up event. As a GEF mechanism depends on the order of both events (see bug #329986), and as the mechanism is working on Windows XP as well as on MacOSX Carbon, the different behavior on MacOSX Cocoa seems to be a regression.
I would argue that Windows is wrong in this case. The mouse leaves the Canvas before the mouse is released, so I would expect the mouse exit to happen before the mouse up.
Actually, I see how this was working in Carbon. In Carbon we call runEnterExit() to generate MouseEnter and MouseExit after an event is handled in Display.readAndDispatch(). This means that the MouseExit will always happen after the MouseUp as desired. In Cocoa we don't do it that way -- we call checkEnterExit during mouse event processing, and it's being called before the mouse down/up/moved is sent. This is fixable; I just need to move the checkEnterExit after the calls to sendMouseEvent.
From a conceptual viewpoint I would basically agree to your first comment, while one may also argue that a drag-operation could be regarded as being kind of "atomic" so that the exit event should not occur before the operation has been completed by a mouse up. From the technical viewpoint, the current behavior in carbon and windows (and potentially all other platforms except cocoa) seems to be quite practical (at least for GEF), as it perfectly supports the use case of dragging/resizing something out of the visible canvas area (in combination will a FigureCanvas that can scroll), while otherwise the drag/resize operation would be "interrrupted" by an exit event. While I would prefer to adjust the cocoa behavior to that of the other platforms (because I do not have to start caching events in GEF to keep track of intermediate exit events), the most important point for me would be to make the behavior consistent across platforms.
(In reply to comment #3) > While I would prefer to adjust the cocoa behavior to that of the other > platforms (because I do not have to start caching events in GEF to keep track > of intermediate exit events), the most important point for me would be to make > the behavior consistent across platforms. This is one of those cases where changing the code to 'do the right thing' is pointless because the original behavior was set in stone so long ago. I have a patch that fixes this, but there's one other place in the code I need to check first.
Fixed > 2010-12-16. Fix for the problem in this bug was easy but Button and other controls that go into NSEventTrackingRunLoopMode needed more testing.
.
