[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 Reply Children
  • Hi Jon

    I use the EXPORT functionality provided with the ITEMTYPES command set (the far right command of the Ribbon, Content, Item Types, Import/Export)
    (I hope you don't mind my explaining further below, for others reading this to learn a bit of background use)

    You have the option to export IT instances from your MODEL to Excel, which is useful for editing in an Excel environment and re-importing to update the instances in your MODEL

    or

    EXPORT the Definition to Excel, which includes all the Fields including Expressions, which is useful for 2 actions;
    backing up your IT Definitions in case they get changed or fail somehow (once changed, the elements that use them are forever altered)
    and
    to COPY an IT Definition from one file to another (if not defined in DGNLIB)

    Greg Smith

    Microstation 10.17.01.058

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

  • 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

  • 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