Going through the task of rolling OBD into my Connect build.
We redefine the location of our user files to a custom location, so why would variables set here be interfering with my build. It's meant that I've had to undefine _USTN_WORKSPACENAME and then lock it so that it doesn't change back to Building_Examples?
Hi Bear, do you mean how to prevent variables set at the organisation level from being overridden at the user level? I came to ask the same question. I can't lock them because they need to be appended at the workspace/workset level.
It's worse than that though Michael, because it seems to me that variables set in the ucf file that we don't use are being read. Building_Examples is set in the personal.ucf file which shouldn't be read as we repath use files early on in our Organisation cfg files.
Already doing that Marc, but I still get this happening with OpenBuildings.
Thanks Marc, It's not an issue of where the user config is saved, or what it's named. It's more that the user config file allows users to modify the behaviour of the client builds. E.G. if a user unticks Autoload in the VBA manager then OB sets MS_VBAAUTOLOADPROJECTS = null in the user config. Then regardless of which client build they open, no VBA projects will auto-load.
Is that something you have different in certain builds Michael. Can't you lock it at the Organisation level?
Nah, I can't lock things at the Organisation level because then the client builds can't add to the variables at the workspace/workset level. MS_VBAAUTOLOADPROJECTS is just an example, it applies to all config variables.
The kill statement is having some unexpected consequences, so I'm still looking for a better fix.
In V8i I had a custom way I loaded the cfg files. Gave up using pcf files, but it meant I could run my cfg files in order, the last being STD_80_Variable_Locks.cfg which I just used to lock variables. The beauty of what I had was that all the company, office, client and project builds loaded before this file did and it meant I could have variables locked down so users couldn't change them.
Harder to do in Connect, but the work around was to load the file at the Workset level. Last line being:
Still means users can't edit locked variables, but the builds can change them. Last step is to lock them down.