My testing is with OpenRoads Designer 10.08.01.33 (2020 Release 2 Update 8) but I believe this is more a MicroStation Connect issue (I have not tested in MicroStation Connect).
default ConfigurationSetup.cfg as below:
[General] _USTN_CUSTOM_CONFIGURATION=C:/ProgramData/Bentley/OpenRoads Designer CE/Configuration/ [SetConfiguration] %if !defined (_USTN_USER_CONFIGURATION) %if defined (_USTN_CUSTOM_CONFIGURATION) && ($(_USTN_CUSTOM_CONFIGURATION) != "") && exists ($(_USTN_CUSTOM_CONFIGURATION)) _USTN_CONFIGURATION = $(_USTN_CUSTOM_CONFIGURATION) %endif %endif
Open a file with one of the installed workspace/workset.
Now change _USTN_CUSTOM_CONFIGURATION (I changed to C:/CADDLib/Connect/ which is an internal location for us)
Open ORD again, when the backstage workspace/workset selector is open check ConfigurationSetup.cfg and (if you have the same problem as us) you'll see the line _USTN_CONFIGURATION has been hard-coded to the _USTN_CUSTOM_CONFIGURATION.
[General] _USTN_CUSTOM_CONFIGURATION=C:/CADDLib/Connect/ [SetConfiguration] %if !defined (_USTN_USER_CONFIGURATION) %if defined (_USTN_CUSTOM_CONFIGURATION) && ($(_USTN_CUSTOM_CONFIGURATION) != "") && exists ($(_USTN_CUSTOM_CONFIGURATION)) _USTN_CONFIGURATION = C:/CADDLib/Connect/ %endif %endif
I can also trigger this by setting _USTN_CONFIGURATION in a different file (for example WorkspaceSetup.cfg), i admit this would be a kind of dumb thing to do but it does trigger it.
Important part seems to be you have to open a file using the one _USTN_CONFIGURATION, then exit, modify _USTN_CONFIGURATION and open ORD again. At that point the _USTN_CONFIGURATION is re-rewritten. If at this point you change _USTN_CONFIGURATION back to _USTN_CONFIGURATION = $(_USTN_CUSTOM_CONFIGURATION) it won't be changed again until you change _USTN_CUSTOM_CONFIGURATION in ConfigurationSetup.cfg (or _USTN_CONFIGURATION in a different cfg file)
This is kind of killing me at the moment because we actually need to change the _USTN_CUSTOM_CONFIGURATION for a particular client and flipping back and forth is going to be necessary. My normal ConfigurationSetup.cfg has logic for detecting this and setting the correct one, but when it does the value is then hard-coded into the configurationSetup.cfg.
I've had problems with the _USTN_CUSTOM_CONFIGURATION variable too.
To get around this I set the value of _USTN_CUSTOM_CONFIGURATION as needed in a different config file that gets loaded prior to the loading of ConfigurationSetup.cfg. After defining the variable I lock it so it can't be changed.
Have you tried moving the logic you have in the ConfigurationSetup.cfg to a custom config file that loads earlier in the startup process?
Rod WingSenior Systems Analyst
Any suggestions for how I can make my workspace available for you guys to look at. I have stripped the dgns and cell libraries, but it is still a 28.9 MB Zip file.
Warren J. MalveauSenior CADD Support SpecialistLos Angeles County Sanitation Districts
a debug file might be a better/easier start to look at what might be your issues.
Timothy Hickman
CADD Manager | CADD Department
timothy.hickman@colliersengineering.com
Main: 877 627 3772|
1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691
OK, here is a debug log of a normal MicroStation session using our network configuration.msdebug_01.txt
And here is a debug log when running using the local configuration instead of the network one.
msdebug_02.txt
Hi Warren,
Please send us C:\ProgramData\Bentley\MicroStation CONNECT Edition\Configuration\ConfigurationSetup.cfg and U:\LACSD_CFG\ConfigurationSetup_LACSD.cfg
Looking at the msdebug files suggests something about one or both of them needs looking at.
Have any files that precede C:\ProgramData\Bentley\MicroStation CONNECT Edition\Configuration\ConfigurationSetup.cfg in thsi list been modified?
(an msdebug file can be imported into Bentley Configuration Explorer via the less than obvious menu that pops down from the Bentley logo at top left, this shows the order of the CFG files but not their contents and lists all variables but not their origins)
Marc
Here they are:
ConfigurationSetup.cfg
ConfigurationSetup_LACSD.cfg
To answer your question, no files prior to ConfigurationSetup.cfg have been modified.
Hi Warren, sorry for the delay in getting back to you.
Those files explain the interesting approach that you have taken.
Am I correct in understanding that provided that a user does not select a different WorkSpace from the Work Page it all works as expected and that ConfigurationSetup.cfg is not modified by the application?
The application behaviour is that the last WorkSpace selected in the UI will result in ConfigurationSetup.cfg being written to. What does one of your ConfigurationSetup.cfg files look like after that?
I've followed your approach of linking to an include file in the [General] section, that works fine, both example and custom configuration are listed.
I left the [Set Configuration] section as delivered, altering that usually results in the application writing statements in the wrong place.
The problem I've encountered is it that once I pick a WorkSpace/WorkSet in the Custom Configuration then exit MicroStation, the next time it starts the example configuration is not listed.
We will have to look into that.
Marc Thomas said:Am I correct in understanding that provided that a user does not select a different WorkSpace from the Work Page it all works as expected and that ConfigurationSetup.cfg is not modified by the application?
CORRECT
Marc Thomas said:The application behaviour is that the last WorkSpace selected in the UI will result in ConfigurationSetup.cfg being written to. What does one of your ConfigurationSetup.cfg files look like after that?
The _USTN_CONFIGURATION variable is modified, but when the file opens, partly opens in the previous configuration. If I close MicroStation and restart, the file opens correctly in the new configuration.
If you have access to Service Requests, SR-7001109434 includes a video illustrating the sequence of events.
Thanks for the link, I will check out that video tomorrow.