I understand from previous forum questions that non basic text should NOT be used for ITEMTYPE names, e.g. "-", "?" etc.
However, I have found an issue with prefixing names with numbers. While acceptable to Microstation and causes no errors in simple usage, an issue arises with Expressions.
e.g.
DATEType = Date/Time
SHORTDATEType=TextExpression = System.DateTime.GetDateOnly(this.DATE)
But, if DATE is renamed to 16DATE, the expression in SHORTDATE fails to parse.
FWIW. This does not fail if "DRAWDATE16" is used. So its not the fact that there is a number in the Property Definition, but the fact the number comes first..
NB. I have not trialled other Expressions for similar issues with number prefix Names.Also, placing the field in quotes e.g."16DATE" allows the field to parse, but it is not evaluated, so the Failure Value (if set) is the displayed result.
The primary purpose I have for prefixing with a number, is so that when the Instances are EXPORTED, I get the fields in the expected order in the resulting Excel file.Otherwise, without some ordering prefix (such as 01, 02, 03 etc.), because the export process sorts based on alphanumeric order, one ends up with a rather non-useful ordering if ITEMS, rather than the order in which the Names are shown in the ITEMTYPE definition, and in the Edit ITEMTYPES display.And yes, I have submitted an Idea request for this ordering.
Gregory Smith said:I understand from previous forum questions that non basic text should NOT be used for ITEMTYPE names, e.g. "-", "?" etc.
Because Item Types are a subset of EC framework (EC XML), the naming rules are derived from this technology. And as its name says, it's "XML based", so Item Types naming rules are XML tags naming rules (see e.g. this page).
When a name, not following the rules, is entered, it's normalized to standard internal format. Usually it's enough to store all not standard characters as Unicode values, surrounded by __ (2 underscores).
Gregory Smith said:But, if DATE is renamed to 16DATE, the expression in SHORTDATE fails to parse.
Yes, it's "by definition" (and similar issues were discussed already).
16DATE is not valid XML name, because it begins with a number, which is not allowed. It means, it has to be normalized to __x0031__6DATE name. It's internal format, which is converted back from Unicode to normal strings automatically when it is displayed.
Gregory Smith said:but it is not evaluated, so the Failure Value (if set) is the displayed result.
Yes, because in fact, property named 16DATE does not exist.
I assume you should be able to see it in Editor (not sure whether Expression editor was available in U14), because Expressions work with internal names, not with display names:
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Hi Jan
Thank you for explaining the reason and how the linkages are with EC, and the link.I is quite annoying that Microstation allows these Names to be used without warning, then fail on certain actions.An error trap could well have been incorporated to control Names.I could not imagine an environment that does not allow free use of at least the basic ASCII characters, letters and numbers. FWIW I only have BASIC programming experience.I'll ensure letters only are used, but of course this persists the main issue I was trying to avoid, the unwanted sorting of Properties on EXPORT :( Hope my Idea is taken up by Bentley. ITEMTYPE Sorting Idea
I hadn't found a discussion that dealt with number prefixes though. Might have been alluded to though in the discussion on hyphens etc.
U14 does not include Expression Builder. I had to revert back from U15 as all our ITEMTYPES failed on opening U14 and earlier Picklists in U15 (Defect 1114952)
Greg Smith
Microstation 10.17.01.058
Opinions expressed are my own and not necessarily those of my employer
Gregory Smith said:I is quite annoying that Microstation allows these Names to be used without warning, then fail on certain actions.
There is no reason for any warning. It's exactly defined in ECXML format specification how naming rules are implemented. And to use e.g. national (non ASCII) characters or names with number is valid, because the normalization is used. But it should be explained in documentation (maybe it is, I have not checked it).
The problem is in gap between defining Item Types structure, which was designed as user tool (in contrast with full EC data structure specification, which is really complex task), and Expressions, that are in fact a part of development, so it's expected authors know what they do and how system works.
With introduction of Expression builder, this problem is decreased, because it's more visual and do not require special knowledge as in previous versions.
Gregory Smith said:An error trap could well have been incorporated to control Names.
I agree there is a space for enhancement. I was able to crash editor and/or complete MicroStation CE U15 several times when playing with Expressions.
Gregory Smith said:I could not imagine an environment that does not allow free use of at least the basic ASCII characters, letters and numbers.
Welcome in world of professional standards and development! :-)
All standard and languages I know and use, including XML (and all protocols based on XML like ECXML, WFS, SOAP...), C++, C# etc, have very strict rules (plus recommended best practices) for naming and what characters are valid in what situation.
Gregory Smith said:I hadn't found a discussion that dealt with number prefixes though.
I remember several discussions about internal names (vs displayed names) both in Item Types and EC schemas in general, in MicroStation and also in MicroStation Programming forums. It's not only about the discussed situation (a name starts with number), but also when any not allowed letter (e.g. char with accent) is used.
Gregory Smith said:U14 does not include Expression Builder.
Expression builder is great tool, because it simplifies the workflow, but it's not mandatory.
When you are not sure about internal names, used by Item Types, you can use "ecx schema export" key-in to export EC schemas from DGN to XML files and to check the definition there.
Jan Šlegr said:Because Item Types are a subset of EC framework (EC XML), the naming rules are derived from this technology. And as its name says, it's "XML based", so Item Types naming rules are XML tags naming rules
While you're absolutely correct, the average MicroStation user doesn't know about the EC framework or XML naming rules. The MicroStation help documentation could publish its own set of rules to help avoid this sort of situation. For example, here are a few paragraphs about Naming Variables in Feature-Based Solids Modelling...
Variable names may have up to 32 characters, with no embedded blanks. They are case sensitive and must begin with a letter, followed by letters, numbers, or underscores.
You cannot create a variable name that is the same as a built-in function or constant, but it may contain a reserved word as part of a name. For example, as "sin" is a built-in function, 'sin' is not a valid variable name. The variable "sin_of_x", however, is valid. Reserved words are not case sensitive, so "Sin" also is not a valid variable name.
A variable's name must be unique within the solid (local variables), or DGN file (global variables), in which it is used.
Gregory Smith said:It is quite annoying that MicroStation allows these Names to be used without warning
Yes: if part of MicroStation constrains object names, then those contraints should be (a) published and (b) enforced. Consider level names, cell names and model names, all of which have similar constraints.
Regards, Jon Summers LA Solutions