<AWT Dev> [8] Request for review: 7092551 Double-click in TextField sets caret to the beginning
Alexander Scherbatiy
alexandr.scherbatiy at oracle.com
Wed May 23 03:34:31 PDT 2012
Could one more person review the fix? I need at least two reviewers
before pushing it.
Thanks,
Alexandr.
On 4/26/2012 2:03 PM, Alexander Scherbatiy wrote:
>
> 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.
>>
>>
>
More information about the awt-dev
mailing list