OBD-U7 - personal.ucf variables

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.

I can't see the sense it the hierarchy.  I guess the developers didn't have mining consultancies in mind when they came up with the plan.

If I can't find a better solution i'll the below code to an OnDesignFileClosed macro.  It's a bit of a flamethrower approach, but most my user tickets can be solved by clearing the user config file.  I'm re-building all our OB connect builds now, getting FMG connect up and running was a marathon.

Dim str_file As String
str_file = ActiveWorkspace.ExpandConfigurationVariable("$(_USTN_HOMEROOT)") & "prefs\Personal.ucf"
Kill str_file

I can't see the sense it the hierarchy.  I guess the developers didn't have mining consultancies in mind when they came up with the plan.

If I can't find a better solution i'll the below code to an OnDesignFileClosed macro.  It's a bit of a flamethrower approach, but most my user tickets can be solved by clearing the user config file.  I'm re-building all our OB connect builds now, getting FMG connect up and running was a marathon.

Dim str_file As String
str_file = ActiveWorkspace.ExpandConfigurationVariable("$(_USTN_HOMEROOT)") & "prefs\Personal.ucf"
Kill str_file

I've had several discussions with Bentley and the reality is there seems to have been very little input from anyone with workspace experience. Instead of working through issues they have simply locked things down which just penalises anyone who knows what they are actually doing. It also greatly limits what we can do with Connect products. Like the kill idea, I can easily write that into my hta.

Hi guys,

I'm not sure if this will fit into your methodology but the crucial step in the configurations that I build is to undefine _USTN_USERCFG which is initially defined by the application. This is needed to allow the default value which is locked very early on to be overridden.

In this example I've set the location of the prefs to be D:\MCE_User\$(USERNAME)\

%undef _USTN_USERCFG         # disable default value
_USTN_USERNAME = $(USERNAME)         # change name of prefs files from 'Personal' to Windows USERNAME
_USTN_HOMEROOT = D:/MCE_User/$(USERNAME)/         # set path to prefs location
_USTN_USERCFG = $(_USTN_HOMEPREFS)/$(USERNAME).ucf         # set UCF name to Windows USERNAME

alternatively to use Aerison instead of USERNAME

%undef _USTN_USERCFG         # disable default value
_USTN_USERNAME = Aerison          # change name of prefs files from 'Personal' to Aerison 
_USTN_HOMEROOT = D:/MCE_User/$(USERNAME)/         # set path to prefs location
_USTN_USERCFG = $(_USTN_HOMEPREFS)/Aerison .ucf         # set UCF name to Aerison 

This may not be the exact set of statements that you need but hopefully the principle applies.

Some earlier notes on this are here:

CONNECT Edition - Configuration Tips : User Preferences in OneDrive or Other Locations - Looking under the bonnet...

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?