<AWT Dev> [8] Request for review: 7092551 Double-click in TextField sets caret to the beginning

Oleg Pekhovskiy oleg.pekhovskiy at oracle.com
Fri Apr 13 06:59:10 PDT 2012


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