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

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Fri Apr 6 03:45:20 PDT 2012


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/

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