Document Information

Document Type: TechNote 

Product(s):  MicroStation

Version(s):  V8

Original Author: Bentley Technical Support Group

Legacy Document Number:  8351

Level Naming and Numbering Conflicts

With the move to MicroStation V8, some users may have abandoned the use of level numbers in favor of level names. Stated more accurately, we may have stopped managing level numbers in favor of level names. The distinction is important because, like level names, every level must have a unique number. Therefore, it is not really possible to stop using level numbers.

Because both the level name and level number have to be unique to the file, one can imagine that MicroStation must be able to resolve potential conflicts when a new level is added to a file that already uses the new level's name and/or number. These conflicts can come from a variety of sources including: a user adding a new level, merge of a reference file, writing a level from a DGNLIB to the active file, and writing a level from a reference attachment to the active file. It's how these conflicts are managed that is the focus of this TechNote.

When using the Level Manager dialog to create a new level, the name field is immediately editable while the number is assigned as the next available number with respect to both the active file and DGNLIB. If the numbering sequence is consecutive starting with 0, the new level's number will be x + 1, where x stands for the largest member of the sequence. If the numbering sequence is not consecutive, the new level's number will be y + 1, where y is the largest member of the first consecutive sequence beginning with 0. For example, if the levels are numbered 0 - 100, the next level number would be 101. However, if the levels are numbered 0, 2 - 100, the next level number would be 1. This is not to say that the level number cannot be edited later using a duplicate number. In this case MicroStation rejects the edit and reports to the Message Center the reason the operation did not return success.

Because the level name is editable until the new level is accepted, the potential exists for a duplicate--if the proposed level name already exists in either the active file or DGNLIB. Should this happen, the conflict is reported in Message Center and level is written using the level name that was generated by MicroStation and displayed previous to the edit. The level name generated by MicroStation is New Level (n), where n begins with 0 and is incremented according to the rules of number assignments discussed above. If, however, the proposed level name was used in a reference attachment, but not in either the active file or DGNLIB, the new level would be written using the proposed level name.

There also exists the potential to create new levels in the active file when either merging a reference attachment, or copying elements from the reference attachment into the active file. Numbering conflicts are handled as described above, however naming conflicts are resolved by setting the reference preference "Copy Levels During Copy..

• If Not Found - Levels from the reference are merged into the output file only if the level name is not already in the active file's level table.
• If Overrides Exist - Levels from the reference are merged into the output file if the level name is not already in the active file's level table, or if the attributes for the active file's level are different than those of the attachment. Differences include overrides that have been applied to the attachment levels, or differences between the levels as defined in the active model and reference.
• Always - Levels from the reference are merged into the output file even if the level name is already in the active file's level table.

These are the conditions under which a new level will or will not be created. When a new level is written, the level name will be prefixed by the reference name. For example, if the level name is LEVEL and the reference name is REF.dgn, the level created during the merge process would be REF - LEVEL.

Arguably the most misunderstood conflicts occur when working with DGNLIB's. There are two ways that a DGNLIB can produce a numbering conflict. The first type of conflict occurs when the same level number is assigned to levels in both the active file and DGNLIB that do not share the same level name. The second type of conflict occurs when two or more DGNLIB's contain levels using the same number, but different level names.

When the conflict between the active file and DGNLIB occurs and an element in drawn on the DGNLIB level, the level number of the level in the active file is renumbered as described above. In addition, the number of DGNLIB level written to the active file is retained. For example, in addition to the Default level, master.dgn contains only one other level. This level is named MASTER and numbered 10. Moreover, library.dgnlib contains a level named LIBRARY and numbered 10. When library.dgnlib is either attached to master.dgn or read in by setting MS_DGNLIBLIST, the level name list with show two levels using the same number. However, when an element is drawn on level LIBRARY, level MASTER will be renumbered to 1. This occurs because as mentioned above, the level number is unique to the file.

When a conflict between the DGNLIB and DGNLIB occurs, the duplicates are discarded in favor of the level read from the first DGNLIB processed. For example, library.dgnlib contains a level named LIBRARY and numbered 10. Additionally, library_two.dgnlib contains a level named LIBRARY_TWO and numbered 10. Assuming that library.dgnlib is processed first, only LIBRARY will appear in the level name list. This is regardless of whether or not the libraries are attached or read in by setting MS_DGNLIBLIST. It is suggested that each DGNLIB contain a unique numbering sequence so as to avoid this potential conflict. Lastly, it's worth mentioning that numbering conflicts do not occur when working with DWG files because level numbers are not stored in DWG files.

Numbering conflicts aside, there is also the potential for the same level name to exist in the active file and the DGNLIB, albeit with different level numbers. When this occurs, the level number of the DGNLIB level is used. It follows that the attributes could also be different, and this would result in the level being out of sync with the DGNLIB. How to handle this is a discussion for another article, but suffice it to say that MS_LEVEL_AUTO_SYNC_ATTRIBUTE_LIST is the option of least resistance. Lastly, if the same level name can exist in the active file and the DGNLIB, the same level name can also exist in multiple DGNLIB's. This is handled by retaining the level from the first DGNLIB processed and discarding the duplicates.

The purpose of the TechNote was to introduce you to the various naming and numbering conflicts that can arise. While some of these conflicts are either virtually transparent or of little concern, others, such as missing levels, are more troublesome. Armed with the information discussed here, things such as missing levels can become a thing of the past. If you are currently missing levels because of a numbering conflict between DGNLIBs, you can quickly renumber the levels in a file using the key-in level renumber increment-value level-spec. For additional information about this key-in, see the help topic "Level Key-ins."

See Also

http://communities.bentley.com/products/microstation/w/microstation__wiki/8861.levels-and-level-libraries

Product TechNotes and FAQs

MicroStation Desktop TechNotes and FAQs

External Links

Bentley Technical Support KnowledgeBase

Bentley LEARN Server

Comments or Corrections?

Bentley's Technical Support Group requests that you please confine any comments you have on this Wiki entry to this "Comments or Corrections?" section. THANK YOU!