Community
Participate
Working Groups
I have the same problem that was reported in bug 104779 a few years ago. The SelectionEvents generated by the ScrollBar widget sometimes do not have SWT.NONE set in the detail field of the event at the end of dragging (especially if I release the mouse button while still dragging). I had a look into the source code (ScrollBar.java) and found something that has not been changed since revision 1.61 (which was the commit for bug 104779) and it looks like this never could have worked: The "detail" field in ScrollBar (which is not the same as in the event) is set to gtk constant values (e.g. OS.GTK_SCROLL_JUMP) but is later checked against SWT.DRAG. Also the "detail" field is always cleared after the switch statement in gtk_value_changed() (in addition to the next line where it is cleared when the "detail" field is != OS.GTK_SCROLL_JUMP), so the check in gtk_event_after will never trigger. I've attached a patch which fixes the problem for me.
Created attachment 176942 [details] This patch should fix the problem
Not sure why they got this wrong in bug 104779. I see your code makes sense, good patch. I'll run a quick test and release it. Thank you very much.
On my machine this always work. SWT.DRAG == GTK_SCROLL_JUMP == 1 and I always was receive a gtk_change_value (not followed by gtk_value_changed) before the key up event-after. -- In your case, I believe you are not getting the last gtk_change_value, so the code that always sets detail = NONE (without testing dragSent) is burning you. The confusing part is need of the dragSent flag, it also wants to make sure the user gets at least one detail=DRAG before sending a detail=NONE (is case gtk_value_changed is never called: the user click the thumb and hold, but doesn't move, then released the button). Anyhow, your code is correct. Fixed in HEAD > 20100820
