Community
Participate
Working Groups
1) Select events 2) Click in the a tab item (make sure focus is in the item) 3) Move the mouse into the client area (do not press a mouse button) 4) Use the mouse wheel to scroll either up or down 5) MouseWheel alternates with MouseExit even though the mouse didn't exit Here is some sample output: MouseWheel [37]: MouseEvent{TabFolder {} time=89216140 data=null button=0 stateMask=0 x=59 y=64} MouseExit [7]: MouseEvent{TabFolder {} time=89216156 data=null button=0 stateMask=0 x=59 y=64} MouseWheel [37]: MouseEvent{TabFolder {} time=89216156 data=null button=0 stateMask=0 x=59 y=64} MouseExit [7]: MouseEvent{TabFolder {} time=89216171 data=null button=0 stateMask=0 x=59 y=64} MouseWheel [37]: MouseEvent{TabFolder {} time=89216187 data=null button=0 stateMask=0 x=59 y=64} MouseExit [7]: MouseEvent{TabFolder {} time=89216187 data=null button=0 stateMask=0 x=59 y=64} MouseWheel [37]: MouseEvent{TabFolder {} time=89216187 data=null button=0 stateMask=0 x=59 y=64} MouseExit [7]: MouseEvent{TabFolder {} time=89216203 data=null button=0 stateMask=0 x=59 y=64} MouseWheel [37]: MouseEvent{TabFolder {} time=89216203 data=null button=0 stateMask=0 x=59 y=64}
Bug in Windows, I was able to generate the same output using windows "Date and Time Properties" dialog and Microsoft Spy++.
Any work around?
It is hard: I don't know how to tell when a WM_MOUSELEAVE is legitime or not. What we can do is not forward the WM_MOUSEWHEEL to the default wndproc for the tabfolder, I suppose it doesn't do anything but forward it up to the parent window.
I remember this one from Smalltalk. If I remember correctly, it can be worked around by playing with WM_NCHITTEST but this breaks something else that is subtle. I believe it is possible to ultimately fix all the places but probably not worth it right now. Low priority.
I don't understand how to WM_NCHITTEST to fix this. Can we relie that a LEAVE event is *always* preceded by a ENTER event ?
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
