<AWT Dev> [8] Request for review: 7092551 Double-click in TextField sets caret to the beginning
Alexander Scherbatiy
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.
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