<AWT Dev>  Request for review: 7092551 Double-click in TextField sets caret to the beginning
oleg.pekhovskiy at oracle.com
Fri Apr 13 06:59:10 PDT 2012
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
> 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.
> 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
> 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.
> 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.
More information about the awt-dev