Handling Level Numbers – User Defined Numbers v/s System Defined Numbers

Like level names, every level must have a unique number.  Because both the level name and level number have to be unique to the file, 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, resolving levels from multiple DGNLIBs, using a level from a DGNLIB in the active file, and copying a level from a reference attachment to the active file.

All these conflicts are best described in the article: http://communities.bentley.com/products/microstation/microstation_v8_2004_edition/w/microstation_v8_2004_edition__wiki/level-naming-and-numbering-tn.aspx

A level number is assigned in two ways: 

1. Assigned by the user, that is user defined numbers
2. Automatically generated and assigned by the System, that is system defined numbers

By default MicroStation is in “System Defined Numbers” mode. But by default the display of such numbers is disabled from the user interface. If the user wants to see the system defined numbers, you need to turn on the capability _USTN_CAPABILITY < +CAPABILITY_LEVELS_USE_AUTO_GENERATED_NUMBERS. In many ways the use of a system generated level number was introduced to avoid the numbering conflicts mentioned in the above article.  The underlying premise of System generated numbers is that they are not interesting to the user. Or stated in other words, if the user is interested in assigning a number to a level then the user needs to explicitly say so, that is make the number a “User Defined Number”. System defined numbers are subject to auto-renumbering to avoid conflicts which could arise with user defined level numbers.  Ideally, the user does not enable the capability variable and treats the system as name driven. 

Fig. 1

 In Fig. 1 you can see the level numbers that are surrounded by asterisks. They are the system defined numbers and are automatically generated by the system when the required capability is turned ON. If the user modifies a level number then the number becomes a user defined number. A user defined number can be changed to a system defined number by clearing the number. The number can be changed in the level manager or can be changed using “Level Properties” dialog (Fig. 2). Fig. 1 also highlights the user defined numbers.

Fig. 2

 Level numbers can be conflicted mostly 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. 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 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.

More blogs coming up, so stay tuned...