I am trying to do some Ribbon customizations and was running into an issue as to where my dgnlib file was located. I thought I was in the proper directory, but apparently I was not, so changes were happening to the "personal.dgnlib" file instead. When I was trying the same process on my laptop, it was actually working properly. Looking at the MS_GUIDGNLIBLIST variable, I see what is happening, but I am unsure as to how to fix it since it seems to be broken at the 'System' level and I've just gone though what I thought were the system .cfg files to no avail...
On the laptop (where everything works fine), this is what I have for the variable:
On my work pc (after commenting many cfg files):
By the looks of it, MicroStation Connect is somehow trying to get my default Documents directory. My laptop is not managed by my IT department, but the pc is on the Domain and I know they manage the Home folder with AD.
The question is: How is MicroStation finding this directory? Is this setting modifiable from a MicroStation config or is it programmatically done?
Yes, I know I can reset the variable using '=', but I normally do not do this in my configurations due to version changes/enhancements.
in my opininon the best first step is to produce msdebug.txt file (start MicroStation with -debug=5 argument, see e.g. this article for more information) both for you work and personal computers. Comparing these two files it will be more clear how the variables are creates and how your home and work configurations differ.
Personally I am not sure if it's correct to try to define customization on system level, MicroStation CONNECT Edition provides new variables, so the configuration is more flexible (in my opinion ;-) and personal.dgnlib defined using MS_PERSONALDGNLIB looks like better approach.
I have two note to the captures you provided (thanks for them, they are helpful):
Final question is: What do you want to achieve? Do you want to have one dgnlib file with your personal customization, so you will be able to share it easily between work and home computer? Or your aim is something different?
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Thanks for reminding me about the debug argument...major brain fart on my end.
The debug confirmed that the variables were still being set by backup files I had in the folder that the system files reside. Had to rename the files to a .bak to prevent them from applying. This allowed me to finally track down what is really going on here.
By looking at the debug file with further testing, the path was set by _USTN_WORKSETROOT which is set inside of ...Configuration\WorkSpaces\NoWorkSpace\NoWorkSet.cfg which set that variable from the Windows variables HOMEDRIVE and HOMEPATH.
Given our setup here in our Domain, HOMEDRIVE = U: and HOMEPATH = \
This essentially should set the variable to U:\\ instead of the U:// that MicroStation is setting it to. Further testing came to the following conclusion that only a developer would be able to confirm - the real problem looks like a auto-format/parser that they have inside of MicroStation Connect.
Given the above examples, the following things happen:
In my opinion, if multiple backslashes are encountered after a colon, then they should be trimmed down to one instance:
U:\\\ to this-> U:\ not this -> U:///
As to your questions: I was just trying to figure out what was causing the U:// that you noticed wasn't correct either. At this point, the configuration setting is not only affecting this setting, but anything else using _USTN_WORKSETROOT in this instance. I am currently developing a new DGNLIB for our organization's menu system and found it odd that it wasn't modifying the file I was inside of even though it should've been modifiable.
Thanks again for your help with that debug option...
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration
To add a few notes Chuck's summary:
The best practices / recommendations for MicroStation configuration files are:
Of course these rules are not strict, so they can be broken, but there should be a serious reason to do it.