[CONNECT] - MS_GUIDGNLIBLIST at system level

Hi Sean,

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):

• The variable is defined on two different levels (System and Organization), which is probably not correct. Msdebug report can provide better insight why it happens.
• In my opinion the value U://Dgnlib/... is not correct. I think slashes should not be a problem, but why double slash (U://) is used? This is not how folders should be defined in Windows.

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?

With regards,

  Jan

Hi Sean,

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):

• The variable is defined on two different levels (System and Organization), which is probably not correct. Msdebug report can provide better insight why it happens.
• In my opinion the value U://Dgnlib/... is not correct. I think slashes should not be a problem, but why double slash (U://) is used? This is not how folders should be defined in Windows.

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?

With regards,

  Jan

Hi Jan,

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.

_USTN_WORKSETROOT=$(HOMEDRIVE)$(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.

HOMEDRIVE	HOMEPATH	Should Concatenate To	Actual Concatenation
U:	\	U:\\	U://
U:	\this\is\a\test\	U:\this\is\a\test\\	U:\this\is\a\test\
U:	\this\\\is\\\a\\test\\	U:\this\\\is\\\a\\test\\\	U:\this\is\a\test\
U:	\\this\\\is\\\a\\test\\	U:\\this\\\is\\\a\\test\\\	U://this/is/a/test/
U:	\this\\is:\\a\\test\\	U:\this\\is:\\a\\test\\\	U:\this\is://a/test/
U:	/this//\is:\\\\\a\\test\\	U:/this//\is:\\\\\a\\test\\\	U:/this/\is://///a/test/

Given the above examples, the following things happen:

• Multiple similar slashes (forward or back) are removed.
• Multiple similar slashes (forward or back) immediately after a colon (:) are not removed.
• Multiple similar slashes (forward or back) immediately after a colon (:) revert all slashes afterward to forward slashes (assumes a web address).

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...

Most (all?) MicroStation Variable Definitions are finished off with a \ or a /. So the assignment of _USTN_WORKSETROOT=$(HOMEDRIVE)$(HOMEPATH)\ is where one \ or / is coming from.
Since HOMEPATH at you site is \ and HOMEDRIVE is U: the assignment of _USTN_WORKSETROOT to U:\\ is to be expected.
At our office, HOMEPATH is defined as \Users\%username% - notice - no trailing backslash.
So in our office, _USTN_WORKSETROOT would add the trailing backslash and it would be a single backslash.
When programming for various purposes, I learned a long time ago that you had to code for all contingencies. So when pulling paths and drive letters, I always added a check for root folders.
However, in MicroStation, a / and a \ are "interchangable" for paths. This dates back to the days when MicroStation was a multi-platform program. Additionally, in most cases, it ignores // or \\ and treats is like a single slash.

To add a few notes Chuck's summary:

The best practices / recommendations for MicroStation configuration files are:

• Use / (slash), not \ (backslash). As Chuck wrote, this is the heritage from Unix times and MicroStation is compatible with both, but / is the recommended standard regardless Windows users \
• If a variable points to a folder and not a particular file, it should always ends with the slash.

Of course these rules are not strict, so they can be broken, but there should be a serious reason to do it.

With regards,

  Jan

this is working as designed:
From the HELP: Contents > Setting Up Projects > Workspace Configuration > Configuration Variable File Syntax

File path names should be entered using the forward slash (/).
Windows converts all forward slashes (/) in new value to backslashes (\).
Also, all directory definitions should end with a trailing forward slash.

This is an example of a valid directory definition: MS_DEF = /network/dgn/

These definitions are not valid:
MS_DEF = /network/dgn #no trailing slash
MS_DEF = \network\dgn\ #backslashes
When editing a configuration variable file, insert a carriage return at the end of the last line to ensure the entire file will be processed.
Press <Enter> to insert a carriage return.

Well, there isn't a chance in the world that I'm going to be able (or anyone else for that matter) to convince an IT person that they will need to change a backslash within a standard Windows variable for a Windows directory to a forward slash since this type of symbology is not really valid for a directory path.  Even so, changing this variable to a forward slash would still resolve _USTN_WORKSETROOT to U:// which is not a valid path.

Essentially the delivered MicroStation configuration file NoWorkSet.cfg potentially does not work with standard Windows variables that are in proper Windows directory syntax dependent on the IT section's setup of Home Folder within Active Directory/Group Policy.

This is just going to force me to use WorkSets now where I may not have had to use them since I mainly setup our Department at a Site level.

Thanks for everyone's thoughts on this matter.