Could someone else review the fix? I need at least two reviewers
before pushing it.
Webrev: http://cr.openjdk.java.net/~alexsch/7092551/webrev.01/
Thanks,
Alexandr.
On 4/13/2012 5:59 PM, Oleg Pekhovskiy wrote:
Looks good for me.
Thanks,
OIeg.
On 4/06/2012 3:45 PM, Alexander Scherbatiy wrote:
Hello,
Please review a fix for:
CR 7092551 Double-click in TextField sets caret to the beginning
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7092551
Webrev:http://cr.openjdk.java.net/~alexsch/7092551/webrev.01/
<http://cr.openjdk.java.net/%7Ealexsch/7092551/webrev.01/>
A Double-click in TextField does not work because the TextField is
based
on the windows EDIT control which does not have EM_FINDWORDBREAK
method.
A solution is to use the RICHEDIT control instead of EDIT. Because the
TextArea also is based on the RICHEDIT control it is possible to make
some unification between AwtTextField and AwtTextArea classes.
Changes:
1) Moving getting RICHEDIT class name from the TextArea to
TextComponent
2) Updating TextField Create method to use the TextArea workarounds.
3) Moving OLE callbacks class defenition and creation to the
TextComponent (both classes TextField and TextArea now use it)
4) EditGetCharFromPos method bodies are differenet for TextField and
TextArea.
Using the old one in the TextField leads to the
EXCEPTION_ACCESS_VIOLATION.
So using the one from the TextArea and moving it to TextComponent.
The issue 7092551 (Double-click in TextField sets caret to the
beginning) is resolved.
Issues:
5) Setting editable for TextField to false does not show gray
background.
Moving workaround for the Enable, SetColor and SetBackground methods
definitions from TextArea to TextComponent
6) Setting an echo char for TextField and double click selects only
part of the echoed text.
Addding checking the echo char to the HandleEvent method where a text
is selected.
7) Adding issue 6417581 workaround to EditSetSel method of the
TextField component.
There is one more workaround 5003402 for TextArea control which needs
to enable the automatic scrolling and there is no need to use it in
the TextField.
8) Move PreProcessMsg method from the TextArea to TextComponent to
workaround filtering the WM_LBUTTONUP after WM_LBUTTONDBLCLK for
RichEdit 1.0
9) CR 6480547 is not reproduced with the RICHEDIT control.
Removing using initialRescroll workaround from the TextField.
Not need to override the Reshape method in the Textfield.
Requested changes:
10) NOERROR is changed to S_OK
11) The OleCallback is not deleted explicitly in the
OleCallback::Release() method.
Only number of the object references is returned.
12) if-else block in the OleCallback::QueryInterface method is unified.
13) Because only the RichEdit 2.0 control is used (and it is not
necessary to support the RichEdit 1.0)
the AwtTextArea::PreProcessMsg method that tries to avoid issue with
the WM_LBUTTONUP event after double click is removed.
The right behavior is that there are 2 WM_LBUTTONUP events after the
WM_LBUTTONDOWN during the mouse double click.
So the RichEdit 2.0 control has a right behavior.
However the RichEdit 1.0 generates a pair of events
WM_LBUTTONDOWN, WM_LBUTTONUP during the double click.
14) Methods merging
- The create method is unified and moved to the AwtTextComponent
class.
- I do not merge the HandleEvent method. They are quite similar in
both classes AwtTextField and AwtTextArea. However there are
differences
in some 'if' branches.
Thanks,
Alexandr.
