This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 120436 - I18N - no visual feedback for input method in UML Document window
Summary: I18N - no visual feedback for input method in UML Document window
Alias: None
Product: uml
Classification: Unclassified
Component: General Diagram (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@uml
Keywords: I18N
Depends on:
Reported: 2007-10-30 06:59 UTC by Ashizawa Kazunori
Modified: 2009-05-25 21:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

image. (5.62 KB, image/png)
2008-07-29 09:42 UTC, Ashizawa Kazunori

Note You need to log in before you can comment on or make changes to this bug.
Description Ashizawa Kazunori 2007-10-30 06:59:57 UTC
I18N - no visual feedback for input method in UML Document window

Product Version: NetBeans IDE Dev (Build 200710281200)
Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06
System: SunOS version 5.11 running on sparc; UTF-8; ja_JP (nb)

To reproduce the problem:

1. create a UML project and create a Use Case diagram
2. open UML Document window if necessary
3. put a Use Case element on the diagram, and select the element
4. click in the Document window, and type Ctrl-Space to enable input method
5. type "aiue", then corresponding Hiragana characters appear
6. type Return to commit the string
7. type Ctrl-A to select all characters
8. type "o", then all Hiragana characters are erased, and empty
   a Hiragana character, which corresponds to "o", should be there
9. type Return to commit this "o", then corresponding Hiragana appears
Comment 1 Ken Frank 2007-10-30 14:53:08 UTC
probably a duplicate of long standing issues, 78353, regarding uml design window
and input of multibyte; many things have been fixed and its known that
some things have not; for nb6 I believe the overall issue has been waived
and the workaround of using the properties window to compose and add the
needed characters.

uml team can decide if this one is a duplicate of that overall issue.
Comment 2 Ken Frank 2008-01-10 19:50:52 UTC
changing to p2 to match priority of other related issues on input of multibyte;
this still might be duplicate of existing open issues - 
can uml team evaluate and see and close this one if it is ?
Comment 3 George Vasick 2008-01-15 22:04:52 UTC
Reviewed and approved for waiver by UML -iteam.
Comment 4 Ken Frank 2008-04-14 22:26:53 UTC
does the upcoming changes to uml include new approach or api
for the areas that get user input, since for input of multibyte
characters there have been many problems and this one is an example ?

if the new things do not impact how the multibyte input is handled,
can this be fixed in trunk so we can then get it into the first 6.1 patch ?
(thats the process)
Comment 5 Ken Frank 2008-05-15 16:29:09 UTC
please fix for 6.5
Comment 6 Peter Lam 2008-05-23 20:55:34 UTC
In NB 6.1 & 6.5, I'm seeing the flashing vertical-bar cursor. Perhaps, this is solaris specific issue.
Comment 7 George Vasick 2008-06-04 23:51:06 UTC
Works on windows, needs to be verified on solaris.
Comment 8 Ken Frank 2008-07-28 20:37:49 UTC

does it work ok for you now using uml for 6.5 ?
please use nb build of 0721 since more recently uml
builds are not in 6.5 ide, but the fix would be in build of 0721.

also, can you see if it looks ok for Chinese also, as to more complex
but normal input ?
Comment 9 Ashizawa Kazunori 2008-07-29 09:41:33 UTC
The problem is still reproducible with trunk Build 200807281401
on Solaris Nevada SPARC and x86.  See attached image.  Preedit
character (in the circle) is positioned incorrectly and hidden.
This problem might not be reproduced with one try.  I will try
Windows later to confirm if this problem is not reproducible.
Comment 10 Ashizawa Kazunori 2008-07-29 09:42:39 UTC
Created attachment 65912 [details]
Comment 11 Ken Frank 2008-07-29 15:48:54 UTC
reopened based on Kasha's comments; also updated version
since it happens in 6.5 now.
Comment 12 Ashizawa Kazunori 2008-07-30 05:16:29 UTC
Confirmed that this problem is still reproducible on Windows XP
SP2 with trunk Build 200807281401.
Comment 13 Yang Su 2008-07-31 18:25:51 UTC
I'm able to reproduce the issue on Windows Vista with latest build and Microsoft Pinyin IME for simplified Chinese, but
only after more than 20 tries. The defect is very minor, once the selection is committed the character is repositioned
at the right place, and subsequent inputs are not affected. P3 or P4 would be more appropriate.
Comment 14 Ken Frank 2008-08-01 01:28:42 UTC
kasha, team is asking if this could be viewed as p3 as per Sheryl comments of today -
what do you think -

does it happen rarely

does it have little impact on other operatioms ?

is it a common ways of doing input for asian characters
and if so, if something is hidden from user seems like a big impact ?

we don't want to cause users in asian locales to do anything special or workaround
if when they are doing normal things; that seems to be a p2 kind of issue IMO.
Comment 15 Ashizawa Kazunori 2008-08-01 05:33:33 UTC
I agree it is not a critical bug.

This problem happens frequently.  The input operation is quite
normal.  It is important for users to see what are being typed
in, as all typed characters are converted, then converted again,
and then user need to decide the result (candidate) is good, and
if not good, convert again.

But I do not think that UML Documentation feature is so
important to make this bug P2.
Comment 16 Ken Frank 2008-08-01 15:15:33 UTC

thanks for the comments.  

I think other issues regrading input of multibyte in other parts of drawing area/design area
of diagram will be fixed going forward - from what I heard the new implementation of drawing
area dooes not include yet about the editing or input, so its possible the other existing
issues about mbyte input are still present also. 

based on his comments, I agree its ok to make this p3.