<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