Bug 79216 - [consistency] attaching a DragDetect listener to a sash affects the selection event
Summary: [consistency] attaching a DragDetect listener to a sash affects the selection...
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Grant Gayed CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: consistency
Depends on:
Blocks:
 
Reported: 2004-11-22 12:48 EST by Platform-SWT-Inbox CLA
Modified: 2019-09-06 03:35 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fai Sigalov CLA 2004-11-22 12:48:40 EST
on Windows, if you attach a dragdetect listener, you'll get one fewer selection 
event.

In control example, go to the sash tab
- attach mousedown, mouseup, and selection listeners.
- press down and up on a sash.
you'll get the following events:

Selection: SelectionEvent{Sash {} time=604321406 data=null item=null detail=1 
x=0 y=144 width=563 height=3 stateMask=0 doit=true}
MouseDown: MouseEvent{Sash {} time=604321406 data=null button=1 stateMask=0 
x=180 y=2}
Selection: SelectionEvent{Sash {} time=604321484 data=null item=null detail=0 
x=0 y=144 width=563 height=3 stateMask=0 doit=true}
MouseUp: MouseEvent{Sash {} time=604321484 data=null button=1 stateMask=524288 
x=180 y=2}

Now attach a dragdetect listener, in addition to the ones above and again click 
on the sash
You'll get the following events:
Selection: SelectionEvent{Sash {} time=604335578 data=null item=null detail=1 
x=0 y=144 width=563 height=3 stateMask=0 doit=true}
MouseDown: MouseEvent{Sash {} time=604335578 data=null button=1 stateMask=0 
x=251 y=2}
MouseUp: MouseEvent{Sash {} time=604335578 data=null button=1 stateMask=524288 
x=251 y=2}

Notice the second selection is missing. Gtk and motif record the same events as 
the first case whether dragdetect is attached or not.
Comment 1 Fai Sigalov CLA 2004-11-22 13:43:26 EST
A similar things happens for scale.
With mousedown, mouseup and selection attached, click on the thumb

You'll get the following events:
Selection: SelectionEvent{Scale {} time=608545937 data=null item=null detail=0 
x=0 y=0 width=0 height=0 stateMask=0 doit=true}
MouseDown: MouseEvent{Scale {} time=608545937 data=null button=1 stateMask=0 
x=72 y=18}
Selection: SelectionEvent{Scale {} time=608546046 data=null item=null detail=0 
x=0 y=0 width=0 height=0 stateMask=0 doit=true}
MouseUp: MouseEvent{Scale {} time=608546046 data=null button=1 stateMask=524288 
x=72 y=18}

If dragdetect is also attached, and the thumb clicked, you'll get the following 
events:
Selection: SelectionEvent{Scale {} time=608591921 data=null item=null detail=0 
x=0 y=0 width=0 height=0 stateMask=0 doit=true}
Selection: SelectionEvent{Scale {} time=608591921 data=null item=null detail=0 
x=0 y=0 width=0 height=0 stateMask=0 doit=true}
MouseDown: MouseEvent{Scale {} time=608591921 data=null button=1 stateMask=0 
x=72 y=17}
MouseUp: MouseEvent{Scale {} time=608591921 data=null button=1 stateMask=524288 
x=72 y=17}

Though an event isn't lost, the order of events is switched.
Comment 2 Fai Sigalov CLA 2004-12-20 11:13:42 EST
fixed > 20041217
fake mouseup in Widget.wm_lbuttondown is now sent using OS.PostMessage
Comment 3 Billy Biggs CLA 2004-12-22 11:38:39 EST
This caused bug 81759.
Comment 4 Steve Northover CLA 2005-01-19 19:52:45 EST
Grant to prioritize.
Comment 5 Grant Gayed CLA 2005-02-08 15:31:19 EST
I've verified that this is working now, it should have been marked as FIXED 
just before Christmas.
Comment 6 Steve Northover CLA 2005-02-08 15:36:54 EST
I don't remember fixing this, especially for a sash ... and we put back the 
SendMessage() in WM_LBUTTONUP because this broke tool bars.  Billy?
Comment 7 Grant Gayed CLA 2005-04-05 11:03:51 EDT
I see the original problem again, and now cheese is left on the sash once the 
DragDetect has been hooked.
Comment 8 SlugFiller CLA 2006-10-06 12:00:57 EDT
Possible fix: On most widgets, this can easily be fixed by NOT using OS.DragDetect, but rather emulating the drag-detection from WM_LBUTTONDOWN/UP, WM_MOUSEMOVE and WM_KEYDOWN. In fact, this is fairly simple to do, since all that has to be done is detect WM_MOUSEMOVE outside of a GetSystemMetrix(SM_CX/YDRAG) box between a WM_LBUTTONDOWN and WM_LBUTTONUP/WM_KEYDOWN(wParam=VK_ESC), then send the dragdetect to the position where the WM_LBUTTONDOWN occurred.

Two possible issues:
1. I don't have WinCE, so I can't be sure, is the behavior there the same?
2. Some widgets call DragDetect from the window proc, so some prevention may be in order there. Alternately, allow these to be handled as they are, since they use a completely overridden WM_LBUTTONDOWN anyway, and don't bare the same functionality as a Sash.
Comment 9 Lars Vogel CLA 2019-09-06 03:35:18 EDT
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 and remove the stalebug whiteboard tag. 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.