Creating Multiple Element Templates at Once Redux

Resurrecting a thread from the Archive MicroStation Forum

I am working with a Client based workspace that is 100% based upon Barmenu MDF files. These can only be converted to Menu customizations - there are no tools to take any of their content and to make Element Templates, Tools or Tasks. With InRoads migration to Open Roads and its increasing reliance on Element Templates, I decided it was time to write some code on my own.

To build a complete XML to make menus, element templates, tools and tasks is proving pretty formidable. With some effort, I can get mostly clean Element Templates - but they often need a fair amount to post creation cleanup. Part of the problem is the MDF files sometimes do things that were not part of their original intent. Some menu lines are missing their action strings and currently, my code reads the MDF files one line at a time and tries to write the XML data on the fly. Other menus activate a tool with no symbology settings - these result in an Element Template which does nothing. And some of these are under a sub-menu. so you end up with a family of empty menu's.

I have experimented with the msxml vba "plug-in" in the past, but not to write XML but only to read XML - so that might help some. Clearly, reading the entire MDF file before writing anything would help to prevent some post conversion cleanup, but I am really still working on a proof of concept version to see if it is really a realistic goal.

So as part of this, I decided to experiment with STG files. This has also proved problematic. I tested using the ASCGROUP.MA file to create STG file from the TXT file as possible with ASCGROUP, but the example TXT file had never been updated to show how you might work with named levels. It took some work, but I eventually discovered there is a setLevel for numeric levels and a setLevelName for named levels.

So this tool works somewhat with the following caveats:

  1. STG files do not support text styles.
  2. The nesting depth in STG file are fixed.
    1. Group Name - user definable
    2. Component Name - user definable
    3. Type - fixed (Text, Linear, Cell, Point, Dimension, Area Pattern & Multi-line
  3. No tasks are created, only tools
  4. Only Generic icon is created

On the plus side - you get tools with element templates already linked.

I also tested placing the text style name in the font name field. Even though the fond does not exist, the name survives even into an XML export. With the properly crafted Reg Expr in Notepad++, I could convert a font name in a text style override into a text style as a bulk process.

So far, I am still on the fence as to where I need to go with this. Anyone else struggling with this? Any other ideas?

Parents
  • Dealing with XML

    Unknown said:
    I have experimented with the msxml vba "plug-in" in the past, but not to write XML but only to read XML

    MSXML

    Microsoft XML (MSXML) v6 is installed with MicroStation V8i.  That makes it easy to reference it from the VBA IDE.  However, that's about the only easy bit.  MSXML is a very elementary interface to XML.  It's a like being obliged to use simple lines to create a complex DGN model: possible, but you might prefer a higher-level approach.

    LINQ

    That higher-level approach for XML is offered by Microsoft .NET.  In particular, C# and LINQ make writing code for XML much more productive than MSXML.

    LINQPad

     LINQPad is a freeware standalone tool for developing and debugging .NET code.  It's particularly useful for reading and writing XML. 

     
    Regards, Jon Summers
    LA Solutions

  • Hi,

    you might find templatecommand a useful tool when dealing with templates. It hooks template change events and fires a associated command.

    Regards, Stefan.

Reply Children
  • Stefan,

    That looks interesting. This client's interface currently uses to barmenu MDL's - one is officially the main one. Once loaded, you can load the others from it. They also have a vba that reads the filename as you open a file which automatically loads the MDF file for that particular file type.

    So I am looking at a number of alternatives. The main MDF flle, once converted using the mdf2xml tool from Bentley, if imported into one of the dgnlibs, combines that menu into MicroStation. For this portion of the process, this makes perfect sense.

    But all of the many other MDF files, and there are 61 in total, for these I need to decide if once I create element templates for any MDF menu line in all 61 of these files that set symbology, should be brought into a single dgnlib or many dgnlibs.

    And then to decide do I want to try and use show/hide tests or some other method to turn off and on the different pieces of this puzzle.

    I think that if users had to scroll through a list of all of the element templates to find a particular one, as opposed to a subset, they might rebel.

    I have loaded up the Tri-Services Workspace which has most of this approach up and running, which uses tasks. I believe my users and the client would prefer this type of transition than to go the command by element template.

    If it was a small number, it makes sense. But with the huge number I have, not so much.


    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996