Answers for the Levelly Challenged


Answers for the Levelly Challenged


Trying to put this in laymen's terms is going to be a challenge in itself. So here we go. When using a DGNLIB file to control your levels you have to consider the amount you want this file to control.


First there are the level names themselves - using a DGNLIB file will give your users a pick list to choose from when drawing an element. They will have a level available to them to choose when the element is drawn. Next are the overrides or by level attributes. Again these are available and the user does not have to make a choice. However - if the user chooses not to use what is presented to them for an attribute, then their change will make level out of sync from the library (and this is ok or acceptable in some cases). If this is not the result needed or accepted, then there is a need to change what the user is actually doing in the file. One way would be to inform the user not to draw in this manner (yeah right). The other would simply be to set a variable that would change what the user has done on the fly (in the background-behind the scenes). Setting the variable MS_LEVEL_AUTO_SYNC_ATTRIBUTE_LIST. Setting this variable to various syntaxes will cause different results. If it is set to ByLevelSymbology or OverrideSymbology it will synchronize the levels in the design file and its references to the attached DGNLIB file. If it is set to LibraryByLevelSymbology or LibraryOverrideSymbology only the design file itself will have its levels synchronized with the attached DGNLIB file. If it is set to ReferenceByLevelSymbology or ReferenceOverrideSymbology then only the active files references will have their levels synchronized with the attached DGNLIB file and not the active file. It sounds a little confusing - if you use the "library" prefix it tells MicroStation to only sync the active files levels, and if you use the prefix "reference" it tells MicroStation to only sync the references of the active file. There is also a manual version of this variable that will allow the user to manually do this rather than it happening automatically (this may be the case if you need to synchronize on a per file basis). Setting the MS_LEVEL_SYNC_ATTRIBUTE_LIST will control all the above functions either when a keyin is used or the "update levels from library" button is selected from the Level Manager dialog box. Again this would be considered a manual process - per file.



One thing to consider when deciding to work with a DGNLIB file is that if you are considering controlling the levels' color, style, weight, etc,,, you will need to make a decision if "overrides" or "by-level" functionality will be used. You can certainly use both, but this will become very confusing for you and your users. So it is best to stick with one during the process of a project.


Remember when using a DGNLIB file for your levels, the level does not exist in the active file, until it is used (meaning an element is placed on that level). Once the level exists in the design file, it is now separate from the DGNLIB file. It has its own settings (overrides, by-level, etc,,,) and if you want this to match what is in the DGNLIB file you will need to configure one of the above variables to make sure your DGNLIB file is followed.


When a level is added to the DGNLIB file, this will be reflected thru all files using the DGNLIB (in other words, the new level will appear in the level list when the design file is opened). However, if a level is removed from the DGNLIB file - this will not necessarily reflect thru your design files. If the level never existed in the design file, then when it is opened, this level will not be seen in the level list. Now if the level was used (existed) in the design file, it will still remain in the level list. In order for this level to be removed from the design file, all elements on this level must either be removed or moved to another level. Once this is done and the level is empty, it can then be deleted from the design file. Elements that exist on a level may not always be graphics. One example would be a dimension style - even though there are no elements on the level, a level containing a dimension style could not be deleted from the design file, until this dimension style is removed from the file, or moved to another level.