Stephen wrote:I suppose the main thing I was trying to ask was what would be the best way of keeping track of a lot of controls.
Why don't you keep in each control an array (std::vector
) of subcontrols (or rather, pointers to subcontrols)? The parent control would be responsible e.g. for deleting the subcontrols in it's own destructor, copying them when it itself is copied, etc.
This organizes your big numbers of pointers properly hierarchically.
An example is that for each button, you give it a pointer to a function (which is executed when the button is pressed).
Just for completeness, instead of a callback function like "OnMenuItemSelected(...)" you might also employ the Command Pattern
for the same purpose. This is what I'm currently changing CaWE to.
Say in this I wanted to change a text box's contents. I don't want to have hundreds of pointer declarations, or deal with arrays (an keep track of which id each control has). So I think that the best way would be to have a name assigned to each control, so I could just do this:
Code: Select all
Why has _Menu[_CurrentMenu]
a method GetTextBox()
? It seems utterly unrelated to me.
How would you implement GetTextBox()
? I think you'd still need to traverse a list of pointers...
I also think both problems would resolve themselves if you employed the parent-keeps-list-of-children approach mentioned above. This is also how things are designed in wxWidgets and the Ca3DE GuiSys.
Oh, btw., why don't you just have a look into the GuiSys header files? They are included with each recent release, and maybe give you some ideas. When I implement more controls for the Ca3DE GuiSys in the future (better text edit control, list boxes, choice/combo boxes, menus, etc.), I'll use just the same interface headers.
Now I just have to work out how to store both the names and their position in the vector... I could probably just use two vectors for that.
You can do that, but I wonder why you don't simply add a member like std::string Name;
to your control (menu, subwindow, etc.) class?