[8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Aug 7 04:33:57 PDT 2012


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.



More information about the macosx-port-dev mailing list