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.
In an IEP project, drag stream Input into the palette window. double click on the stream Input icon. You can not input any JA data into any of the text fields. my OS is windows xp running in JA locale
George, does this happen when using im tools for entering mbyte or with copy/paste also ? could you attach gif of the window if convenient ? ken.frank@sun.com
It happens for both input and copy/paste. Attaching a gif does not help because when I do the input, nothing shows up in the text field.
true for any iep component properties editor - can't input multibyte at all. ken.frank@sun.com
was able to input mbyte into the comment section of relationship aggregator, but not the attribute name or some other parts. actually there are various prop editors of iep components where even ascii cannot be input or focused to add input ken.frank@sun.com
Operator names in IEP are like method names in Java, and attribute names in IEP are like variable names in Java. It has to start with any thing in the set {_, a through z, A through Z}, and followed by any thing in the set {_, a through z, A through Z, 0 through 9} The editor only considers these as valid inputs. We may change this in the future by extending the IEP language.
method and variable names in java can have multibyte, thus I don't think this is a valid restriction if indeed what is legal in java is what is legal in iep editor. but if it needs to be restricted, can there be some clue or error msg - since in this case, the user is doing the usual way of typing multibyte but sees nothing happening and that is confusing. ken.frank@sun.com
In the stream Input editor you should be able to enter multibyte for database column names. The database does allow multibyte data for column names.
There was an objection from Ken. Waiting for resolution.
Not a stopper accoriding to Ken. However migh be visible for users: "I was just clarifying that some i18n things, like these bugs, would be visible to users of the en beta, who run in other locales"
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
To dev team - can you confirm that this will be fixed in hula ? Its not related to translations at all, since can impact any user who runs in other locale and who might use characters of that locale, and use of such characters is legal in java. ken.frank@sun.com
It was a bad analogy to method names and variable names in Java. The operator names and attribute names are used to generate event processors in CQL language. The CQL engine can only process operator names and attribute names that are composed of _, letters, and digits. We will enhance the engine to allow more characters in the future.
Thanks for clarifying about the QL - as per previous comments, I do think a warning or other information should be provided to the user about this - if they use their normal ways of input of extended ascii, multibyte or other non ascii chars, and it just does not work, it will be confusing to them since this is an editor, it seems it can be a bit more challenging as to where to place the warning and how, vs for a single dialog, wizard or property. Also, please add to even beta1 release notes, since this is not related to translations at all. But on the topic of translations - will translated messages/labels in this editor be able to be shown ? ken.frank@sun.com
Translated messages/labels in this editor will be able to show.
Blu, IMO this is not an enhancement; its an issue that needs to be fixed via giving a warning or some other way vs user seeing that the usual way they input non ascii appears to be broken. that is, the way multibyte (and other non ascii) is entered is a standard way, and doing it that way in iep props editor it does not work and will be confusing to them; since the props editor looks like any other props editor in ide. Thus I understand that the fix should not be to allow such input, but to warn the user they can't do it; and hopefully block such input rather than allowing it since when its allowed, it looks partially broken, for example for ja on solaris, I see the candidate characters but they are not shown. Also, are there any props of iep pallette items where non ascii is allowed as values ? Am changing back to defect. kenf.frank@sun.com
seems like iep project is back in nb6.1/sierra and thus if editor is also, this needs to be fixed for nb6.1 can dev team comment about it ? also, can other i18n things about iep project, file types, editors, etc be done if not already - if you file separate issues or tasks can you add kfrank and kaa to interest list ? ken.frank@sun.com
IEP will not be part of NB 6.1 FCS I believe.
Sergey, just to reconfirm, the iep project, file type, editor, etc that is seen now in nb6.1 builds, which I am assuming now has all sierra functionality that was in separate builds - all this functionality will noto be in 6.1 fcs ? if so, could it be removed soon ? (let me know if 6.1 trunk builds are not the place where sierra functionality is) ken.frank@sun.com
Ken, I confirm that IEP will not be in 6.1 fcs. Ritesh, would you please work with NB Release Engineering to exclude IEP modules from NB 6.1 build.
started
Fixed, Two changes are done: (1) Now whenever an invalid name is entered, user is shown a popup tooltip like message about invalid character. (2) Added a system property iep.editor.validateNamesInTextField (by default the value is true), this can be set for example in netbeans.conf ex: -J-Diep.editor.validateNamesInTextField=false if this property is set to false as shown above then we by pass the name validation and allow user to enter whatever name they want. This could fail in runtime if user enters invalid names which make some iep database sql invalid, but at least we have a way to allow user to enter what they want and they should make sure names are valid so that sql is valid.