[CONNECT] - MS_GUIDGNLIBLIST at system level

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.

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

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

  • Unknown said:
    There isn't a chance in the world that I'm going to be able 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

    You don't need to. Operating system environment variables should be defined in whatever way is suitable for the operating system.  MicroStation configuration variables are not operating system environment variables.

    MicroStation configuration files are designed to be operating-system agnostic.  Years ago, the same configuration file worked with, say, UNIX, MS-DOS and Windows NT.  Times have changed, and the only operating system of interest is Windows 7 etc.  Or is that the only game in town?  We are seeing Bentley Systems products on Android and other operating systems, so it may be that agnosticism will be required once more.

    When MicroStation processes its configuration files, operating system environment variables are evaluated as required.  If one of your configuration files finds a Windows environment variable MY_WINDOWS_FOLDER it evaluates it for subsequent use as it processes other configuration variables.  The appropriate directory separator characters are used or substituted as required.

    Define operating system environment variables as required by your operating system.  Define MicroStation configuration variables following the rules for those variables documented in MicroStation help and repeated by Bill Robinson and Jan Slegr above.

     
    Regards, Jon Summers
    LA Solutions

  • Unknown said:

    Define operating system environment variables as required by your operating system.  Define MicroStation configuration variables following the rules for those variables documented in MicroStation help and repeated by Bill Robinson and Jan Slegr above.

    I totally agree with this.  The issue is that a delivered configuration file tries to utilize two Windows variables...HOMEDRIVE and HOMEPATH.  By default with a Windows 7+ (maybe Vista also, but I never really used it) machine not connected to a Domain, these variables default to:

    HOMEDRIVE - C:    HOMEPATH - \users\<username>

    In a Domain situation where the IT department utilizes the Home Path option in Active Directory, the HOMEDRIVE variable is set to a drive letter associated to a UNC path and the HOMEPATH will be set to "\".  There really isn't an easy way to change this behavior if my memory serves me right...

     I initially opened this thread just to find out what was causing the weird result that was happening (U:// instead of U:\) since I've never come across it before.  Instead, all I received were comments on how I should be setting up my configuration files and proper syntax.  My issue with this is that I never set this file up to begin with and it has all the proper syntax...yet the directory doesn't resolve correctly.  I've setup config files and scripting for the past 25 years now (yes, back in the UNIX days as well), so I'm pretty well versed in the proper syntax and understand why the slash is used instead of backslash.  On my call into Bentley today, I did mention that maybe they should've finally ditched the Unix syntax since it's been at least 15+ years since I know when we last used one of those machines, but your explanation with potential hurdles with other OS's in the future seems like a valid reason not to change the current system. 

    After looking into this a bit more tonight, I want to reach out to Bentley development to attempt to fix this issue.  If I remember correctly, if a user's Home Path is set from Active Directory, then the HOMESHARE variable should also be set.  This variable does not exist (please correct me if I'm wrong here) if the Home Path is not set from Active Directory.  I have tested the following code in the configuration file in question and it seems to work fine for me on both my laptop (not part of a Domain) and my pc:

    Exist Code:

    %if exists ($(HOMEDRIVE)$(HOMEPATH)/Documents)
      _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/Documents/
    %else
      _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/
    %endif

    Proposed Code:

    %if exists ($(HOMESHARE))
     %if exists ($(HOMEDRIVE)$(HOMEPATH)Documents)
        _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)Documents/
     %else
      _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)
     %endif
    %else
     %if exists ($(HOMEDRIVE)$(HOMEPATH)/Documents)
        _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/Documents/
     %else
      _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/
     %endif
    %endif

    If anyone else would like to confirm whether this code does/doesn't or should/shouldn't work, please do so. If there seems to be a consensus that this should work, I'd like the files delivered by Bentley to be changed.

    Thanks again,

    Sean

  • Unknown said:
    In a Domain situation where the IT department utilizes the Home Path option in Active Directory, the HOMEDRIVE variable is set to a drive letter associated to a UNC path

    MicroStation configuration file processing comprehends UNC path names.  You can use a UNC path in a MicroStation configuration variable...

    MY_SERVER = //ServerName/
    MY_FOLDER = $(MY_SERVER)cad/dgn/

    Unknown said:
    Proposed Code

    Your proposed code convinces me.  You've avoided completely any double-slash or double-backslash issues by using only configuration variables and environment variables. 

    However, the test for $(HOMESHARE) results in the same definition for _USTN_WORKSETROOT whether or not $(HOMESHARE) is defined.  Of course, you may have reduced the content for illustration, and you may want to add more statements depending on whether that test succeeds or fails.

     
    Regards, Jon Summers
    LA Solutions

Reply
  • Unknown said:
    In a Domain situation where the IT department utilizes the Home Path option in Active Directory, the HOMEDRIVE variable is set to a drive letter associated to a UNC path

    MicroStation configuration file processing comprehends UNC path names.  You can use a UNC path in a MicroStation configuration variable...

    MY_SERVER = //ServerName/
    MY_FOLDER = $(MY_SERVER)cad/dgn/

    Unknown said:
    Proposed Code

    Your proposed code convinces me.  You've avoided completely any double-slash or double-backslash issues by using only configuration variables and environment variables. 

    However, the test for $(HOMESHARE) results in the same definition for _USTN_WORKSETROOT whether or not $(HOMESHARE) is defined.  Of course, you may have reduced the content for illustration, and you may want to add more statements depending on whether that test succeeds or fails.

     
    Regards, Jon Summers
    LA Solutions

Children
  • Unknown said:

    MicroStation configuration file processing comprehends UNC path names.  You can use a UNC path in a MicroStation configuration variable...

    MY_SERVER = //ServerName/
    MY_FOLDER = $(MY_SERVER)cad/dgn/

    Yes, I already do utilize MicroStation configuration variables in our Site file (for example):

    DELDOT_RESOURCES = //dotfs08/cadd/Active_Designs/msv8/
    DELDOT_MDL = $(DELDOT_RESOURCES)mdlapps/
    MS_DGNLIBLIST > $(DELDOT_RESOURCES)dgnlib/deldot_levels.dgnlib
    MS_DGNLIBLIST > $(DELDOT_RESOURCES)dgnlib/deldot_textstyles.dgnlib

    Unknown said:
    However, the test for $(HOMESHARE) results in the same definition for _USTN_WORKSETROOT whether or not $(HOMESHARE) is defined. 

    I'm not quite sure I follow this...the test for %ifexist $(HOMESHARE) should fail on a machine that doesn't have its Home Folder managed by Active Directory:

    If this is the case, it will not result in the same definition for _USTN_WORKSETROOT.

    However, on a machine that does have the Home Folder managed by Active Directory:

    $(HOMESHARE) would resolve to the same location as $(HOMEDRIVE)...only with a UNC path vs. a drive letter.  With this, the proposed code could also be written:

    %if exists ($(HOMESHARE))
     %if exists ($(HOMEDRIVE)/Documents)
        _USTN_WORKSETROOT = $(HOMEDRIVE)/Documents/
     %else
      _USTN_WORKSETROOT = $(HOMEDRIVE)/
      %endif
    %else
     %if exists ($(HOMEDRIVE)$(HOMEPATH)/Documents)
        _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/Documents/
     %else
      _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/
     %endif
    %endif

    or even as such if UNC paths are desired:

    %if exists ($(HOMESHARE))
     %if exists ($(HOMESHARE)/Documents)
        _USTN_WORKSETROOT = $(HOMESHARE)/Documents/
     %else
      _USTN_WORKSETROOT = $(HOMESHARE)/
      %endif
    %else
     %if exists ($(HOMEDRIVE)$(HOMEPATH)/Documents)
        _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/Documents/
     %else
      _USTN_WORKSETROOT = $(HOMEDRIVE)$(HOMEPATH)/
     %endif
    %endif