Tested in MicroStation CONNECT 10.17.00.209
At one time I thought you could prevent a variable from being set in a later config by undefining it, then locking it.
But when I actually tried this with the MS_DISALLOWRELATIVEREFPATH variable it didn't work, as a test I tried:
MS_DISALLOWRELATIVEREFPATH = 1
And the variable was still being set.
Interesting one. I'm not surprised to find that the undefined state cannot be locked, that seems logical.
Please can you describe the use case you are hoping to solve?
Hmmm, maybe the real issue I should be reporting is the scenarios where variables set to 1 are enabled but setting to 0 doesn't disable it, but I'm not sure if that would be a serious breaking change for how a lot of companies do configurations.
I would expect setting a variable =0 would disable it so reporting any cases where it does not would be very useful. Do you see this if ProjectWise is not involved?
Yes, inside or outside of projectwise for MS_DISALLOWRELATIVEREFPATH and CIVIL_UPGRADE_PROMPT_OFF
ORD group confirmed the CIVIL_UPGRADE_PROMPT_OFF will operate if it's set to 1 or 0, the only way to always get a prompt is to %undef it and manually make sure it doesn't get turned back on.
Is setting CIVIL_UPGRADE_PROMPT_OFF=0 the same as %undef it? - OpenRoads | OpenSite Forum - OpenRoads | OpenSite - Bentley Communities
There are a number of variables that work that way. You define it to any value and the option is enabled, the only way to disable the option is to %undef the variable.
I've not had the need to do what you are doing, but I can see the value in being able to do so.
Rod WingSenior Systems Analyst