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.
%undef VARIABLE %lock VARIABLE
But when I actually tried this with the MS_DISALLOWRELATIVEREFPATH variable it didn't work, as a test I tried:
%undef MS_DISALLOWRELATIVEREFPATH %lock MS_DISALLOWRELATIVEREFPATH MS_DISALLOWRELATIVEREFPATH = 1
And the variable was still being set.
Hi Kevin,
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?
Marc
This occasionally comes up for us where we don't want a variable set, but a downstream client configuration may set it (or workset configuration out of our control) may set it. There are some variables where just being defined is enough to trigger the action, no matter what it is set to.
Currently I use it for 2 variables that I consider somewhat important (although in double-checking I see one of these I can actually set to 0 to disable it):
# This blocks supressing the workset association dialog when you open a file # associated with one workset in a different workset. %undef MS_SUPPRESS_FILE_WORKSET_ASSOCIATION %lock MS_SUPPRESS_FILE_WORKSET_ASSOCIATION # Setting this variable will upgrade all civil files to the latest schema with no prompt # We don't want that! %undef CIVIL_UPGRADE_PROMPT_OFF %lock CIVIL_UPGRADE_PROMPT_OFF
I don't want files auto-upgrading in ORD or chaning the workset being used without the user's being aware of it. But sometimes are our clients want these disabled so the user can go directly into the file with zero prompts (I can understand this if you're only running one version of ORD or are constantly getting files from outside consultants that are in the wrong workset name, but it's the reverse for us).
However in writing this I've found I should be able to define MS_SUPPRESS_FILE_WORKSET_ASSOCIATION = 0 then lock that for that one to be permanently disabled. Couldn't get a clear answer on CIVIL_UPGRADE_PROMPT_OFF if I could do the same there.
I came across this issue in testing MS_DISALLOWRELATIVEREFPATH. Normally for projectwise i set it to 1 and then lock in that state, but we were seeing some weird issues so i wanted to turn it off. I set it 0 and %lock that but that turned out not to actually turn it off. So then I %undef and then %lock it, but that also didn't work (I ended up testing in a area that didn't have the client's workspace attached to actually test it).
Not sure how many other variables there are where the help says "set to 1" to turn it on but setting to 0 doesn't actually turn it off.
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