I have a general plea to make something I’m doing easier. No real solution in mind, but you guys are smart…
Like everyone, we build different products. Each product has a particular configuration which evolves. Version 4 might use one file list, and version 4.1 uses a different one. We really want a .ini file or something to capture this configuration. We also want it to be easy to update, without having to hack .ini files directly. What I’m currently doing works, and is easy on the user (currently me), but a bit tough and error prone on the developer (me):
1. Scan for .ini files in a directory, and let the user choose one
2. Load variables out of that .ini file
3. Use a variable prompt to let the user update the values of any of those variables
4. By default the values are saved to the same file they came from, but the user can do a “save as”, making it very easy to update the file for 4.1 or whatever.
5. Variables are saved.
Sounds great. The difficulty is that every persisted variable has to be specified in three places:
1. Load from file
2. Present to user
3. Save to file
These three actions are quite far from each other, making maintaining the variable lists trickier.
Some kind of solution would be nice.
(Actually, writing this out, I see one partial solution I could implement: a variable that contains the names of the variables that I want persisted and load/save by iterating over that list)
Steve
PS No more critical errors, apparently. Yay!
well, it’s almost home time and i’ve run out of good ideas for the day. my initial thoughts would be to use some kind of user definable PropertySet (as they have Load/Save type actions and other actions can be made PropertySet “aware”). anyone else?
I have to admit I haven’t actually used propertysets or filesets as I’m worried they lack flexibiilty. The application support for them is also not as good: you can’t define them at design time, you can’t put watches on them, etc. Also, you apparently need to explicitly copy them to variables (PropertySet to Variable) - which means you need duplicate variables.
I guess I would get more use out of some enhanced variable type that contained fields, that could be accessed like “%Build.name%”, “%Build.Description%” etc.
Steve
you can access PropertySets like that… eg. %MyWin32VersionNumbers.MajorVersion%