Community
Participate
Working Groups
Eclipse 3.2 M6 If you double click, but during the second click, you move the mouse slightly, then, the double click selects from the start of the word to the current location of the mouse. It seems to work fine in a plain StyledText. This didn't happen in 3.1 and I believe it started between M4 and M5. It is certainly happening M5.
That's the first part to deliver bug 5138 and fixing bug 22880. You can now double-click drag but not yet with auto-word selection. As a result if you double-click and drag a bit it only partially selects up to the cursor location. We plan to fully fix bug 5138 in 3.3. We think that doing the select on mouse down and partially allow to double-click drag overweights what you experienced.
Ok but WORKSFORME doesn't seem like the right resolution. It doesn't work.
You're of course right and I agree, but INVALID and FIXED are also not appropriate and it's also not directly a dup of bug 5138.
As long as it gets fixed.
Please add a drag threshold that must be exceeded before you undo what the double-click did.
Don't care but we need to do something about this. Double click is broken compared to 3.1.
I can add code that restores the double-click seletion on mouse up if the selection is smaller than the initial double-click selection. This gives the same ugly look as in 3.1.x where the double-click selection is set on mouse up instead of mouse down. Nicer would be if we could leave the selection untouched while moving the mouse inside the first double-click selection. Steve, any hint how we could tell the widget not to set the selection in this case?
Steve, you could add the threshold detection in StyledText itself, so that doMouseLocationChange doesn't run until 4 pixels or more.
A text field or this text box inside IE does not swipe until the 5th pixel. Click exactly on the middle of a character and try to swipe that character. You have to move pretty far even though you have crossed the midpoint already.
>Steve, you could add the threshold detection in StyledText itself, so that >doMouseLocationChange doesn't run until 4 pixels or more. Note that StyledText works correctly if setDoubleClickEnabled(true) is set.
> Note that StyledText works correctly if setDoubleClickEnabled(true) is set. It is true by default, yet the behavior is not consistent with native text controls in IE. I am referring to swiping, not double-clicking.
>It is true by default, yet the behavior is not consistent with native text >controls in IE. I am referring to swiping, not double-clicking. Not sure what you mean here. The text viewer sets it to false. In other words: if you have a problem with the setDoubleClickEnabled(true) mode then please file a separate bug report against Platform SWT - this bug is the wrong place. Note that the 3.1.x behavior is really ugly: you get no feedback while dragging with the mouse down. Only after releasing the mouse the selection is set/surfaced. I have the code ready that restores the first double-click selection in case where the selection at mouse up has same x but smaller y value selection value.
The bug starts off like this: "If you double click, but during the second click, you move the mouse slightly" I noted, the platform (win32) *ignores* slight mouse moves. Therefore, StyledText should mimic this behavior and ignore slight mouse moves. If this were done, the problem would all but go away. I don't even know what setDoubleClickEnabled does, except that when I created a snippet to test StyledText, it had the default value (true). I was not referring to the CUEditor. Maybe SWT could just add the threshold check, and then in a future release allow you to consume the MouseMove event so that it doesn't cause swiping. If you're going to hack around it, why not hammer the selection on MouseMove?
I guess I misunderstood you. Filed bug 138568 to track the suggested changes to StyledText.
I added a workaround but there will be some flickering. There is currently no way we can correctly fix this because there's no API in StyledText to disable it's selection behavior. In order to fix this and also fix bug 5138 without flickering in the UI we need either of the two APIs from StyledText: - allow to temporarily disable its own selection behavior, so that we can control it - (preferred) allow to set a double-click strategy or word detector that is used fordouble-click and double-click drag I've captured this in SWT bug 138579. Fixed in HEAD. Available in builds > N20060426-0010.
The third option is that SWT allow you to consume the mousemove event by setting doit=false. I'm not sure if there is precedence for doit=false for mouse events. At least it wouldn't require any new API.
Intercepting the mouse drag is already possible using a Display filter.
Here is a snippet which solves the original problem: public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); final StyledText text = new StyledText(shell, SWT.MULTI | SWT.V_SCROLL | SWT.WRAP); text.setText(System.getProperties().toString()); final Listener filter = new Listener() { public void handleEvent(Event event) { switch (event.type) { case SWT.MouseDoubleClick: if (event.button == 1) Display.getCurrent().addFilter(SWT.MouseMove, this); break; case SWT.MouseMove: if ((event.stateMask & SWT.BUTTON1) != 0 && text.isFocusControl()) { event.type = SWT.None; break; }// else continue to remove filter default: Display.getCurrent().removeFilter(SWT.MouseMove, this); } } }; text.addListener(SWT.Deactivate, filter); text.addListener(SWT.MouseUp, filter); text.addListener(SWT.MouseDoubleClick, filter); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } Steve, please comment on the sanity of this approach, and reopen if you think it should be used.
Seems crazy to filter like this at the last minute.
(In reply to comment #19) > Seems crazy to filter like this at the last minute. ....because..... Memory leak concern? Probably need to add a dispose listener in case the widget is disposed while the filter is listening (although disposal would imply deactivate event). Another risk could be that the filter is added twice. I don't see how it could happen, but to guard against it, you could always call remove before add. Or is it crazy because event notification is a mystery on each platform ;-)
Nevermind. I guess there is no way of knowing all of the places (including client code) that rely on that event being sent.
>Seems crazy to filter like this at the last minute. No way I would add such code at this time.
(In reply to comment #22) > >Seems crazy to filter like this at the last minute. > No way I would add such code at this time. OK guys, I think I get the point. I was just trying to show all of the possibilities that did not require new API, since that is not even on the table.
Don't take it the wrong way. Your hacks have paid off in other places by showing that a path exists to a solution.
Verified in I20060512-0010.
