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

  • Agreed, if you wish to just have an output form of your data.

    I wish to use the Export to Re-Import after using Excel to add detail and clean up the data as this is much faster than doing it using the edit IT tool, or the "spreadsheet" function inside Microstation.
    Apologies for not describing this second step, but trying to keep the original Discussion short and to the point, i.e. Naming.

    The traps for newbies here is, do not change fields (Properties) controlled by Expressions, and if the field is limited by a Picklist, then ensure you choose the data from an export of the Picklist also.

    E.g. I have sites with thousands of IT elements, and many of these have similar Properties grouped by name, e.g. TYPE.
    It is very much easier for me to just load the NAME only in at time of entry and CELL placement (IT attached to CELL definition), then EXPORT the IT data to Excel, edit the file and IMPORT back in, thereby applying all the elements with their respective IT data.

    One cannot do this (as easily) with a Report as the output formats differ and so is not conducive to IMPORT command.
    Yes, one COULD Export AND Report all the raw data, then juggle data in Excel, but the potential for error is too high, IMO.

    And of course, as Jan points out in many discussions, IT is a "layman's" use of EC, in which case IT shall be as simple and graphically easy to use as possible, include MORE error trapping, and contain complete and accurate documentation, because it is not necessarily those programming type professionals using IT, but professionals in other disciplines trying to use a tool specifically provided for them.

    Great tool Bentley, and great discussion guys, IT has certainly been a boon for our discipline (beating a certain package's ATTRIBUTES hands down), but please, step up to the plate with the finer points discussed here before getting all jazzy and moving on.

    Greg Smith

    Microstation 10.17.01.058

    Opinions expressed are my own and not necessarily those of my employer

  • 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

  • I use the EXPORT functionality provided with the ITEMTYPES command

    There are advantages to using a Report.  In a Report Definition you can define...

    1. Included Item Type property data
    2. Included DGN element data
    3. New names for Item Type or element properties
    4. Column order

    You can place a Report as a Table or export in formats including Excel.  I think that the combination of (3) and (4) above might solve your problem.  A Report lets you define exactly what is available to Excel, and how it is named.  The UI in a Report Definition lets you shuffle the column order any way you want.

     
    Regards, Jon Summers
    LA Solutions

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

    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.

    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.

    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.

    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.

    With regards,

      Jan

  • 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