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.
Compile doesn't work because of invalid character in ja EUC locale on Solaris platform. Please correct the line below of "Antenna.java" under usersguide/j2seexamples/GUIFormExamples/src/examples. jComboBox2.setModel(new javax.swing.DefaultComboBoxModel(new String[] { "X +45\260" }));
This is the degree sign that is seen in some places in the visual design. ken.frank@sun.com
I think the original antenna.java file or something happens when its created or read in when new project is created -- it has incorrect character/encoding on the line in java file where compile fails (where x_45 degree sign is) but other notations of degree in java file are ok. When any change in designer is done to any component, so that the java file is rewritten, the degree sign appears ok and it compiles ok. This happened in ja locale, did not happen in zh locale, but since this is not l10n issue since examples not localized, it might happen in any other locales. see attachments for how code looks before and after change and see how degree sign is represented in each. ken.frank@sun.com
Created attachment 28085 [details] image
Created attachment 28086 [details] image
Created attachment 28087 [details] image
The original java file in the examples jar file has the notation for degree that causes the problem - the other notations for degree in the java file are correct - ie jLabel1.setText("Direction [\u00b0]:"); ken.frank@sun.com
I am sorry I am not able to reprocuce the problem. Could you, please, describe exact steps to reproduce. I tried to start the IDE in ja_EUC locale, create GUIFormExamples project, open Antenna form and compiled it and it works fine.
Are you running on solaris, using ja locale ? it was seen both by Masaki and myself separately. (I dont think there is a solaris ja_EUC locale name, it is just ja, which is alias for ja_JP.eucJP. Also, bring up the file itself, as unzipped separately from the jar file that has the examples, in a viewer that can show mbyte properly; you can then see the improper character. The steps are as you mention and is mentioned in original report, making sure not to edit or cause the java file or project to be saved or edited once project is opened for first time. ken.frank@sun.com
Honzo S., I am able to reproduce it too in zh_CN locale.
Finally I was able to reproduce this issue. You don't have to set another locale - it is sufficient to change file.encoding to EUC_JP. The problem is in StringArrayEditor that doesn't encode non-ASCII characters. It should be fixed by now. The Antenna template has been regenerated to contain the \u00b0 escape sequence. /cvs/form/src/org/netbeans/modules/form/editors/StringArrayEditor.java,v new revision: 1.4; previous revision: 1.3 /cvs/usersguide/j2seexamples/GUIFormExamples/src/examples/Antenna.java,v new revision: 1.3; previous revision: 1.2
Created attachment 28146 [details] Fix of the Antenna dialog.
Created attachment 28147 [details] Fix of the StringArrayEditor.
I've reviewed the fix - it looks correct and safe.
Seems to be ok in the trunk 200601031900 build.
Wouldn't it be best for the editor to automatically escape Unicode characters inserted into its Document that were not expressible in the selected document encoding when it wrote the document back to disk?
Fixed also in release50 branch. /cvs/usersguide/j2seexamples/GUIFormExamples/src/examples/Antenna.java,v new revision: 1.2.4.1; previous revision: 1.2 /cvs/form/src/org/netbeans/modules/form/editors/StringArrayEditor.java,v new revision: 1.2.14.1; previous revision: 1.2
Verified in the build 200601042030
to jglick: I could possibly implement that (we are already preprocessing the inserted text by replacing "\r\n" by "\n") but there does not seem to be any standard way to express document's encoding (I've searched JDK classes like j.s.t.Document, EditorKit, DefaultEditorKit etc. with no success). We would probably have to make up a key for document.getProperty() e.g. string constant "locale" or Locale.class. On component's level there is j.a.Component.getLocale() but I need it on Document's level for document content insertions so I'm not sure whether we should attempt to reuse the Component.getLocale() at all. What do you think?
Component.locale() is useless here. Rather than the actual java/editor module (with the editor kit) doing this escaping, perhaps the java module could do it upon saving the document. At this time you know where you are saving to, and presumably you can look up the encoding then (this information is available to JavaDataObject anyway). But I'm not sure.
It is nice that this one is fixed but form/src/org/netbeans/modules/form/editors/StringArrayEditor.java is more or less copy of core/src/org/netbeans/beaninfo/editors/StringArrayEditor.java. Does it mean that we can get into similar trouble anywhere in the IDE where string array is edited?