You probably already know this Eric, but in case you don't: the limit on the number of controls is for the number of handles, not the actual number of controls. Meaning you can make a control array and dump 3 or 4 things in to it, and free up that many spaces. Since the control arrays can be unlimited in size, the limit only forces you to do things a little differently. For some controls, arrays might not be a good idea, but for things that are passive, like labels, you can clear up all sorts of control slots by dumping all of them in to an array.
Turns out the limit in VB is on actual controls be they in arrays or not. Putting controls in arrays doesn't impact the limit. I've tried it. I think VB control arrays are just a convience for addressing as far as I can tell. I'm pretty sure each control in an array still has it's own underlying Windows handle for tabbing, short keys, etc.
Au contraire. I have many warm, happy, fuzzy memories of moving labels from free floating to control arrays to free up room for new controls. Ah, the hours wasted... Anyway, you can find some informal proof in
these discussions, where it's mentioned as the way around the limit. Not that I'm saying we need more controls!
I think we need to take a Thoreau view towards GUIs and simplify, simplify, simplify. But at the same time some functionality needs to be modifiable outside the source code, for specialized needs. I'm not sure what a good solution is. However, in general, these are the guidelines that I work with (in general, not just Darwinbots):
- New users don't like controls
- Experienced users like controls
- Some settings are tweaked quite often, and should be easy to modify.
- All settings need to be tweakable somehow.
- Their should be a practical widget for every control. (As an example where this failed: Visual Studio 2005 let's you change the intermediate directory for C# projects only by editing the .csproj file in a text editor, and even then finding that you can do this is hard since the .csproj files and options aren't well documented.)
The requirements as listed suggest a hierarchy of options: one top level that is as simple as possible, and a sub layer where more controls are exposed. However, then you run in to problems of how to display settings in the newbie top layer that have been tweaked in the advanced sub layer. And there are problems with ensuring that both forms are in sync with the game data and each other. Adding a new control requires modifying both forms, and you've effectively doubled the maintenance for GUI components.
Another option, as I mentioned, is to allow users to edit "advanced" features by editing the settings file as a text document. But this always has the feel that what you're doing is back-door and sneaky, especially if the rest of the program is totally GUId. As the case with Visual Studio demonstrates.
Also, the optimal solution, from a programmer's standpoint, needs to provide a zero-error way to add new controls and sync them with the game data. This means one point in the code where all forms communicate with the settings structure, and one place where the settings communicate with the GUI. Preferably the same place, and preferably it could be done automatically in some way.
So I don't know a good solution, but I'll keep thinking about it.
...Apple is very good at this. Microsoft, not so much.
I guess I think like a developer. I don't use many Apple products, but almost every program I use daily is Microsoft. And I understand how the products I use work, and can tell you what almost every option or field does.