Bug 106024 - Combo and Text#setSelection(int, int) does not handle start > end with SWT.SINGLE
Summary: Combo and Text#setSelection(int, int) does not handle start > end with SWT.SI...
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Steve Northover CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 64665
  Show dependency tree
 
Reported: 2005-08-04 06:27 EDT by Markus Keller CLA
Modified: 2011-10-18 07:09 EDT (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2005-08-04 06:27:16 EDT 
I20050803-0800

In a Text widget with text "abc", the behavior of #setSelection(int, int)
depends on whether the flag SWT.SINGLE is set.

- with SWT.SINGLE, setSelection(3,1) sets the caret to position 3
- without SWT.SINGLE, setSelection(3,1) sets the caret to position 1

The second behavior should also apply for the SWT.SINGLE case. This would also
match the documented behavior of StyledText#setSelection(int, int).
Comment 1 Steve Northover CLA 2005-08-23 13:26:19 EDT 
Sorry, it's not possible to set the i-beam location to the start or end of the 
selection on Windows.  Hence, the behavior is not specified.
Comment 2 Dani Megert CLA 2008-02-11 09:12:01 EST 
It seems that the behavior has changed (didn't verify that the initial comment 0 was true though): now (3.4 M5) the caret is always on the right side no matter whether SWT.SINGLE is used or not.

Is there really no way/API on Windows to set a RTL selection?
Comment 3 Dani Megert CLA 2008-02-11 09:25:55 EST 
>It seems that the behavior has changed
Not if the selection is set after opening the shell.
Comment 4 Steve Northover CLA 2008-02-11 12:45:27 EST 
Ok, there is a work around that doesn't set the selection to fix the classic "widget is zero sized, I set the selection, the widget scrolls, I resize the widget then I'm mad when the widget is scrolled" bug.  It sets the selection and probably doesn't get the i-beam in the right place.

Can you confirm that this is what is going on?  (ie. this is the behavior change)
Comment 5 Markus Keller CLA 2008-02-12 05:16:07 EST 
(In reply to comment #4)
I don't think there really was a behavior change. Dani got tricked by a snippet that sets the selection before opening the shell. In that case, the caret always ends up at the end of the selection. But that's a different problem and not the subject of this bug.

The problem as described in comment 0 happens when the text widget is already visible (e.g. reproducible in the ControlExample). To implement bug 64665, I had to use a rather drastic workaround: I implemented all selection change actions from scratch and introduced a "logical" caret position, which does not match the visible caret. That does not look nice, but it works as long as the user only changes the selection via keyboard.
Comment 6 Dani Megert CLA 2008-02-12 06:27:39 EST 
>I don't think there really was a behavior change. Dani got tricked by a snippet
>that sets the selection before opening the shell.
So it is.
Comment 7 Dani Megert CLA 2011-10-18 07:09:54 EDT 
Same is true for Combo.