I don't like dgnlibs because it is not obvious what is stored in which dgnlib.
Now we have level libraries in dgnlibs. Which is the active file looks in another file for the data.
So why can't we have the active file look in something more transparent and readable than a dgn? Like a csv, or a xls, which can be viewed parallel to the active dgn in ustn.
It would also be much easier to edit than through LM in ustn.
Unknown said: I don't like dgnlibs because it is not obvious what is stored in which dgnlib.
That depends on your configuration. AFAIK we aren't limited to the number of DGNLIBS we can use so a good practice that I employ is to keep 1 dgnlib for 1 configuration item alone and not pile multiple settings into 1 dgnlib so I end up with something like:
"Its pretty much a fool-proof setup and if there is ever any glitch at least I can pin-point while file to investigate, plus it also means I don't have to have MS_DGNLIBLIST and MS_GUIDGNLIBLIST sharing the same values."
The problem I have encountered with this approach, which is sort of the way I do it, is things seem to creep into some of the other .dgnlibs and I have had difficulty tracking down where they are. You get a text style in your dimension.dimlib. or a level in your tasks.dgnlib. It would work if we had good drop and drag interface to show everything and where it was coming from .... but we don't.
As for levels they can easily be stored in a 2D table format. Allowing them to be in a REAL .csv format would allow robust management via linking to Excel or Access. So if were not provide a good tool set at least we can do it ourselves. XML is a programmers tool not a users tool there is no reason to complicate a simple 2D table structure with XML.
We either need better tools that work with the exiting format or a better format that we can use our own tools on, or ideally both.
I will aggree about the garbage already in or "creeping" into a dgnlib. However once I've cleaned them all I've now gotten sued to them and like them. and I am a grumply soul. It would just liek to see some better tools to make it feel not so much like programming all the time.
Ustn since 1988SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64bEric D. MilbergerArchitect + Master Planner + BIMSenior Master Planner NASA - Marshall Space Flight CenterThe Milberger Architectural Group, llc
Barry
in perfect world and if you remember exactly what you thought two years ago and never did anything wrong that might be a system.
But i have many more things to think of than where I stored some task two years ago. So at each point in time when I need this information I should be able to find out by the UI.
Text and dimstyles you can, if you happen to find out. But not levels.and other things.
regards / Thomas Voghera
Hi Barry,
Though this works for some items and in some cases it does not work for anything that has a dependency on another item. For instance a Dimension style may use a text style. Once this occurs you have a copy of your text style in the Dimension style DGNlib. If you make a change to what is believed to be your source of truth (text_styles.dgnlib) it wont be seen by your dgns as when we process the variable MS_DGNliblist we take the first instance of the text style we find and that would come from the file dimensions.dgnlib.
Now the first thing people will say and has been said in this thread is to just make a variable for each of the types of thing to be found, for instance MS_DGNliblist_TextStyle. Well that doesn't work either. Take the scenario above. If you use the dimension style before the text style then the text style from the dimension style file is brought into the active dgn. Thus you are using the wrong definition.
The best solution is to have things that are cross dependent placed in one file. In your case the first 3 things should be in one file. I go as far as to say that MS_DGNLibList should include the the variables MS_CELLLiblist and MS_Seedfiles. This way your management dialogs get a true picture of all the content that is out there that may be appearing in your files.
HTH,
John