I noticed that, NSWindow's windowNumber is NSInteger, which is 32 bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a simple 32 bit int is probably not what you intended to do.
Also, have you considered simply calling -[NSWindow setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then removing the calls that flip it on and off in -[AWTView mouseEntered:] and -[AWTView mouseExited"]? This would also require a change in Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), which has a comment that states it only turns on mouse moved events if the window is currently under the mouse. I would think that AppKit should be more than happy to send you mouse-over/enter/exited events as long as you say you want them. Was this approach tried and didn't work for some reason? Regards, Mike Swingler Apple Inc. On Aug 7, 2012, at 4:33 AM, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > Hi, Alexander. > Probably all this stuff can be simplified? Can you try to change TrackingRect > to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag > etc. > > 07.08.2012 15:17, Alexander Scherbatiy wrote: >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >> >> This is a regression after the fix 7154048 [macosx] At least drag twice, the >> toolbar can be dragged to the left side. >> >> In the case where a toolbar is created under a mouse and it is dragged over >> the initial window the mouse enter/exit events should not be generated for >> the components which are under the toolbar. >> >> The current fix is supposed to solve this regression and also to fix >> generation of mouse enter/exit events for all cases where a mouse is dragged >> from one window to another or a new window is created under a mouse (like it >> is implemented for toolbar). >> >> Let's see the following cases >> 1) Mouse is dragged from a window and back to the same window. >> The Mac OS X system generates a mouse exit event only the first time when a >> mouse is dragged from a window and does not generate mouse enter/exit events >> next times during one drag trace. >> >> 2) Mouse is dragged from one window to another. >> The Mac OS X system does not generate mouse enter/exit events for the >> second window. >> >> 3) Mouse is dragged from one window to another and released. >> In this case the Mac OS X system generates mouse enter event for the second >> window only after releasing the mouse. >> >> 4) Clicking on window creates a new window after that the new window is >> dragged (toolbar dragging). >> >> However the Java system generates mouse enter/exit events each time when a >> mouse is dragged over any window. >> >> To fix this the following methods are introduced: >> - Get topmost window under mouse >> - Synthesize mouse enter/exit events for all windows >> >> >> The dispatchMouseEvent method from the LWWindowPeer class is handled >> previous and next components and is able to generate mouse enter/exit events >> for them. >> However the the AWTView native class contains isMouseOver flag which value >> becomes inconsistent if we do not updated it. Because of this the fix >> generates the mouse enter/exit window events on the native side. >> >> Generating mouse enter/exit events always should be in order where mouse >> exit events are generated before the mouse enter events. >> >> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate >> mouse enter/exit events for all windows during mouse drag or window >> creation/window bounds changing. >> However only those windows which isMouseOver flag is differ from the >> isTopMostWindowUnderMouse state are affected. >> This method also tries to generate both mouse enter and exit event for the >> same window but only one of them can be applicable because the >> isTopMostWindowUnderMouse state is not changed for these calls. >> >> So the window enter/exit events now are always generated from the native >> system and component enter/exit events are generated in the LWWindowPeer >> class. >> >> LWWindowPeer class now uses three links to components: current, last and >> topmostUnderMouse. All of them are necessary because in case when a mouse is >> dragged from one window to another the current component receives drag >> events and last and topmostUnderMouse links handle components mouse >> exit/enter events on the second window. >> >> Thanks, >> Alexandr. >> >> > > > -- > Best regards, Sergey. >
