On 10/08/2011 05:41 PM, Pavel
Porvatov wrote:
I got your point. What about this solution:
If in the compose mode, endCompositoin just
sendComposedText instead of sendCommittedText.
The patch is attached
Could you please explain the fix? May be it removes NPE but
it puzzles me. So if buffer.length() == 0 you invoke
sendCommittedText, right? But sendCommittedText commits
buffer, but buffer is empty. Looks strange...
BTW: the code like "if (!notInCompositionMode) {" a little
bit difficult to understand =) I'd preffer to avoid two
negations and use "if (notInCompositionMode)" and swap
if/else blocks...
Regards, Pavel
Hi Pavel,
Sorry for the confusion. Here is some explanation, please
correct me if I am wrong:
1. There two modes which is judge from the buffer size:
composed mode when the buffer size is not zero and normal mode
when the buffer size is zero.
Right
2. The original code make no difference whether
it is in the composed mode or normal mode. In the normal mode,
which buffer size is zero, it sends the committed text. In the
composed mode, which buffer size is not zero, it also sends
the committed code. And NPE occurred here.
3. In the patch, I do not change the logic when in the normal
mode. (notInCompositionMode branch) Why? I guess it is the
logic of "Ends any input
composition that may currently be going on in this context.
Depending on the platform and possibly user preferences,
this may commit or delete uncommitted text. " from the
api spec....
Yes. But after your change the following code looks strange for
me:
if (!notInCompositionMode) {
....
} else {
>>>> sendCommittedText();
}
So if we are not in composition mode we send something (empty
string actually). Logically we shouldn't send anything (IMO),
because buffer is empty. Why should we do something at all if
endComposition is invoked and we are not in composition mode?
4. In the patch, the logic in the composed mode
is that: if it is in the composed mode, keep every thing as
just composed :-)
I found a new bug (???) in the fix. If you apply the patch, run
the MouseEventTest2 test and follow the instructions from the
bug description NPE will not be thrown, but the JTextArea
remains in composition mode even after endComposition
completion.
Right. It seems that we have to do some thing in the jdk :-). Here
it is:
The patch attached is just adding a null check at the beginning of
the mouseClicked method in DefaultCaret. So why the component is
null in the DefaultCaret? That because the caret has already been
deinstalled. It seems to be an order problem of mouse event and
the event which endCompositon sent. The endComposition will
exchange the caret and deinstall the old one. On the other hand,
mouse click event was happening on the old caret. So the component
of the old caret is null now. NPE happens.
It looks that you are trying to fix the consequence, but not the
root of the problem. The endComposition method shouldn't send
anything to deinstalled DefaultCaret. I think the previous version
of the fix was much closer than this one.
Regards, Pavel