<AWT Dev>  Request for review: 7092551 Double-click in TextField sets caret to the beginning
alexandr.scherbatiy at oracle.com
Thu Apr 26 03:03:24 PDT 2012
Could someone else review the fix? I need at least two reviewers
before pushing it.
On 4/13/2012 5:59 PM, Oleg Pekhovskiy wrote:
> Looks good for me.
> On 4/06/2012 3:45 PM, Alexander Scherbatiy wrote:
>> Please review a fix for:
>> CR 7092551 Double-click in TextField sets caret to the beginning
>> A Double-click in TextField does not work because the TextField is
>> on the windows EDIT control which does not have EM_FINDWORDBREAK
>> 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.
>> 1) Moving getting RICHEDIT class name from the TextArea to
>> 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
>> Using the old one in the TextField leads to the
>> 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.
>> 5) Setting editable for TextField to false does not show gray
>> 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
>> - I do not merge the HandleEvent method. They are quite similar in
>> both classes AwtTextField and AwtTextArea. However there are
>> in some 'if' branches.
More information about the awt-dev