I wonder if it is possible to search for a specific string inside a configuration variable.
%if contains("Test", $(SOME_VARIABLE))...do stuff...%endif
Maybe someone knows the answer to this one?
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
MS_LEVEL_SYNC_ATTRIBUTE_LIST = ByLevelSymbology,ByLevelMaterial
_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.
Microstation 08.11.09.829Power GeoPak 08.11.09.878Power InRoads 08.11.07.615
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)