Anton,
this version looks fine to me.
/Alex
On 29/10/15 19:08, Anton Litvinov wrote:
Hello Alexander,
The second version of the fix, which addresses your suggestion
concerning introduction of a separate method checking, if the
"unichar" belongs to certain Unicode blocks, was created. For this
purpose the method "-(BOOL) isCodePointInUnicodeBlockNeedingIMEvent:
(unichar) codePoint;" was introduced. Could you please review the
second version of the fix.
Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.01
Thank you,
Anton
On 10/29/2015 3:09 PM, Anton Litvinov wrote:
Hello Alexander,
Thank you for review of this fix. Responses to your questions are
following.
1) I also was not able to find any methods available in
"java.lang.Character", "java.lang.Character.UnicodeBlock",
"java.lang.Character.Subset" classes or API in Cocoa which would
allow to get minimal and maximal code point for the given Unicode
block. I do not think that resuming work on RFE JDK-7057645 created
in 2011 will help to resolve this particular bug, because it will not
be possible to introduce a new API in JDK 8, for which this bug was
originally filed.
2) Yes, I think that "aString" can have more than 1 Unicode
character, since it is described as "The text to insert" in the
documentation of the method "(void)insertText:(id)aString
replacementRange:(NSRange)"
(https://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSTextInputClient_Protocol/#//apple_ref/occ/intfm/NSTextInputClient/insertText:replacementRange:)
And, if "aString" contains more than 1 Unicode character, this case
was already taken into account by "(utf16Length > 2)" check.
"AWTView.m" without this fix:
893 if ([self hasMarkedText] || !fProcessingKeystroke ||
(utf16Length > 2)) {
"AWTView.m" with this fix:
894 if (utf16Length > 2) {
895 aStringIsComplex = YES;
3) Concerning creation of a separate function for checking, if
"unichar" belongs to certain Unicode blocks. Did you mean addition of
the possible function which would just check, if "unichar" is in any
of the Unicode blocks hard coded in the function? Or did you mean the
function which would just check, if "unichar" belongs to 1 Unicode
block, whose identifier is transferred to the function, for example,
as some "enum" value?
Thank you,
Anton
On 10/28/2015 5:21 PM, Alexander Scherbatiy wrote:
On 10/27/2015 1:18 PM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8132503
Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.00
The bug consists in the fact that after the fix for JDK-8068283,
when IDEOGRAPHIC FULL STOP character "。" is entered from a
keyboard using Pinyin IM, "java.awt.event.InputMethodEvent" is not
generated and FULL STOP character "." is entered in
"javax.swing.JTextArea" component.
The solution adds the additional check to "if" condition, which was
edited by the fix for JDK-8068283,
"if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length
> 2)) {"
in the method "- (void) insertText:(id) replacementRange:(NSRange)"
from the file
"jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m".
This additional check defines, whether the analyzed code point
belongs to Unicode code points range "U+3000 – U+303F" ("CJK
Symbols and Punctuation"), which contains "。" character and, if it
is so, generates "InputMethodEvent".
It was interested for me does Cocoa or Java allow to get a
minimal and maximal character for the given Unicode Block.
I was not able to find how to do it in Cocoa.
Java has an open RFE JDK-7057645 Add methods to
Character.UnicodeBlock (returning first & last codepoints, the list
of blocks).
May be the current issue can be one more valid use case for the RFE.
I have just few comments:
- aString is treated as NSString. Can it have more than one
Unicode character?
- It could be better to move the check that a unichar belongs to
a separate function that can be easily extended later for new
Unicode Blocks.
Thanks,
Alexandr.
It was verified in a local environment that the regression test
from the fix for JDK-8068283 does not fail with this fix also.
Thank you,
Anton
