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.
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
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. ken.frank@sun.com
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 ? ken.frank@sun.com
Reviewed and approved for waiver by UML -iteam.
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) ken.frank@sun.com
please fix for 6.5 ken.frank@sun.com
In NB 6.1 & 6.5, I'm seeing the flashing vertical-bar cursor. Perhaps, this is solaris specific issue.
Works on windows, needs to be verified on solaris.
kasha, 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 ? ken.frank@sun.com
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.
Created attachment 65912 [details] image.
reopened based on Kasha's comments; also updated version since it happens in 6.5 now. ken.frank@sun.com
Confirmed that this problem is still reproducible on Windows XP SP2 with trunk Build 200807281401.
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.
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. ken.frank@sun.com
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.
kasha, 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. ken.frank@sun.com