[CE U14] - ITEMTYPE - Names and effect on Expressions

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.

DATE
Type = Date/Time

SHORTDATE
Type=Text
Expression = 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.

Parents
  • 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).

    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.

    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

  • 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.

    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

Reply
  • 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.

    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

Children
No Data