When opening .dgnlib files to edit levels, text styles, or whatever, I am often confronted with the WorkSet Alert dialog.
Since dgnlibs will be used by multiple WorkSets I usually like to have mine not branded - No WorkSet. Sometimes, however, I'll be in a hurry and just click the Open button on the alert dialog, and brand the dgnlib to my active WorkSet. So far I have not encountered any adverse effects of branding vs. not branding dgnlibs.
Is there anything good or bad about branding your dgnlibs, not branding your dgnlib to a WorkSpace, or doesn't make any difference?
it's very good question, I have thought about it several times in the past also :-)
I think there should be no problem, because DGNLIBs, when opened by MicroStation, are scanned for specific type of data and other are ignored (e.g. you can have any graphic elements in it and MicroStation does not complain).
But I hope somebody from Bentley will be able to confirm it and to provide more details. In fact, in situation when any DGN should contain workspace / workset information and DGNLIBs, by their definition, are typically shared over more worksets or even workspaces, I would expect clear best practices explanation from Bentley ... but I do not recall any such document.
Labyrinth Technology | dev.notes() | cad.point
I tend to agree with you, that it doesn't really make a difference.
The one situation where it may make a difference is if you're editing a .dgnlib file that requires resources from another dgnlib. For instance editing levels that require custom line styles from a linestyle .dgnlib file or colors from a color book .dgnlib, dimension styles that require a text style from a different .dgnlib. Not having them branded, or branded to different WorkSets is a problem because your active session of MicroStation may not find those other dgnlibs.
As far as referencing them in a Configuration it does not appear to make a difference from what I can see.
There shouldnt be an issue with having the dgnlibs branded to a workspace/workset but ideally i would say it best to work in a no workspace/no workset environment so other dgnlib content gets loaded when working in the file.
i can file an enhancement to suppress the alert dialog if the file is a dgnlib is this would find that helpful.
Rod Wing said:The one situation where it may make a difference is if you're editing a .dgnlib file that requires resources from another dgnlib. For instance editing levels that require custom line styles from a linestyle .dgnlib file or colors from a color book .dgnlib, dimension styles that require a text style from a different .dgnlib. Not having them branded, or branded to different WorkSets is a problem because your active session of MicroStation may not find those other dgnlibs.
Most of these things would write the other thing into the DGNlib when it is used so they wouldn't be dependent on the source DGN being needed (Element Template/Feature definitions is the system where this isn't true). This is actually why I would rather work on DGNlibs with No WorkSpace/WorkSet active. If you aren't loading things from any DGNlib other than the active files it helps reduce the amount of repetitive information that is created. It's also why I prefer to keep a minimum number of DGNlibs as possible. If I need to get a text style etc from another file its a deliberate action to get it and I need to think about where the things need to live.
This is a great question. We are using OpenRoads Designer and Bentley themselves have multiple dgnlibs in their workspace that need resources from other dgnlibs to function. i.e., Graphical Filters , display style rules, feature definitions, and element templates that use linestyles, textstyles and dimstyles. The only way to edited these libraries is the have a workset associated with the file. What do we do? Also , as these dgnlibs get copied into Projectwise the workset data will go with them. From what I have read this screws up your managed workspace in Projectwise. Bentley, Please give us some direction.