[MS Connect U14] - Find string inside configuration variable value

Do you have an example of what you're trying to do? You can use VB to extract parts of a variable which you can assign to a new variable and test against. Other than that I'm not sure what else you could do.

Do you have an example of what you're trying to do? You can use VB to extract parts of a variable which you can assign to a new variable and test against. Other than that I'm not sure what else you could do.

Concerning office standards there are a few variables that are "critical" to set (at least for us): MS_DGNLIBLIST, MS_SEED, MS_CLTBL. There are older projects where I still have to maintain v8i configuration while on the same time trying to introduce Connect Configuration with new office standards. This makes things a little bit more complex than I would usually like to set it up.

On some projects I want to add project dgnlib files to existing office dgnlib files, on others I want to override office dgnlib files with project dgnlib files. Same for seed files and maybe for color tables. To get this done in a clean way I introduced a variable _IA_STANDARDSTYPE with possible values of EXPAND, OVERRIDE and FORCESTANDARDS. So when I set this variable in my workset cfg I can react to this in other cfg files. Something like:

%if $(_IA_STANDARDSTYPE) == "EXAPND"
MS_DGNLIBLIST > foo.dgnlib
%elif $(_IA_STANDARDSTYPE) == "OVERRIDE"
MS_DGNLIBLIST = foo.dgnlib
%endif

This works as expected. But now I realized that sometimes I would like to have EXPAND for dgnlib and OVERRIDE for seed.

One solution would be: _IA_STANDARDS_DGNLIB and _IA_STANDARDS_SEED... and so on.

On the other hand I remembered variables like MS_LEVEL_SYNC_ATTRIBUTE_LIST = ByLevelSymbology,ByLevelMaterial where you have a comma seperated list. And I thought something like

_IA_STANDARDSTYPE = DgnLibExpand, SeedOverride, ColorForce

would be nice.

I hope this explains my thought.

As those things should be evaluated at startup I think that VB wouldn't be appropriate. Or am I wrong on this? And even if this would be possible I think I still would like to keep configuration stuff inside configuration files.

Do you use project configurations at all? That would be my suggestion for project-specific settings.

The comma-separated CFG variables are actually a list of settings, as in the list is really a list, not an array of other variables. I don't have any idea how to parse that list.

Yes, we do. Those would be the place to put the _IA_STANDARDSTYPE variables.

I don't want to put MS_DGNLIB or MS_SEED variables there if I can avoid it because when I need to change some more basic stuff of the configuration I may have to rewrite a lot of those pcfs. Also I want to keep the pcf side as clean and small as possible so that other administrators can deploy new projects easily. However I will think it through whether that would also be a practical solution.

Project pcf files would be the best way to do things, but what you have is another good option. You could also have the build look for a cfg file in a project location and add it to the project if you need to make some changes.

$if exists (<project>.cfg)

%include <project>.cfg

%endif