Hi,
It is most likely possible to dynamically add controls (such as text/combo boxes or buttons) to a dialog window in C++ (using MFC), but I wouldn't know how. Can anyone tell me how to do this? The idea is to be able to have my proggie read some script or config file which specifies what controls should be present on each screen, etc. So, I would need to be able to create arbitrary controls at run-time as specified by the script. Any help would be appreciated.

Greets,
Mark

: Hi,
: It is most likely possible to dynamically add controls (such as text/combo boxes or buttons) to a dialog window in C++ (using MFC), but I wouldn't know how. Can anyone tell me how to do this? The idea is to be able to have my proggie read some script or config file which specifies what controls should be present on each screen, etc. So, I would need to be able to create arbitrary controls at run-time as specified by the script. Any help would be appreciated.
:
: Greets,
: Mark
:
:
1. You have to keep an array of pointers (CPtrArray) somewhere in your window/dialog class to hold these controls.

2. Now when reading a script you dynamically create the controls with 'new' and add these pointers into the array from step #1.
Do not forget to call 'Create()' method to create actual HWNDs for these controls:

CButton* pBtn;
CEdit* pEdit;
CListBox* pList;
UINT typeFromScript;

// Parse the script and set the 'typeFromScript'
// You have to define some IDs because they should be used
// when you call 'Create()' - so you can receive notifications
// from your controls.
switch (typeFromScript) {
  case CT_EDIT: // You have to define these by yourself
    pEdit = new CEdit;
    pEdit->Create (...);
    m_arrMyControls.Add (pEdit);
    break;
  case CT_LIST:
    pList = new CListBox;
    pList->Create (...);
    m_arrMyControls.Add (pList);
    break;
  case CT_BTN:
    pBtn = new CButton;
    pBtn->Create (...);
    m_arrMyControls.Add (pBtn);
    break;
}

3. When you finished at all with your page call 'delete' on every pointer in your array.

: : Hi,
: : It is most likely possible to dynamically add controls (such as text/combo boxes or buttons) to a dialog window in C++ (using MFC), but I wouldn't know how. Can anyone tell me how to do this? The idea is to be able to have my proggie read some script or config file which specifies what controls should be present on each screen, etc. So, I would need to be able to create arbitrary controls at run-time as specified by the script. Any help would be appreciated.
: :
: : Greets,
: : Mark
: :
: :
: 1. You have to keep an array of pointers (CPtrArray) somewhere in your window/dialog class to hold these controls.
:
: 2. Now when reading a script you dynamically create the controls with 'new' and add these pointers into the array from step #1.
: Do not forget to call 'Create()' method to create actual HWNDs for these controls:
:

: CButton* pBtn;
: CEdit* pEdit;
: CListBox* pList;
: UINT typeFromScript;
: 
: // Parse the script and set the 'typeFromScript'
: // You have to define some IDs because they should be used
: // when you call 'Create()' - so you can receive notifications
: // from your controls.
: switch (typeFromScript) {
:   case CT_EDIT: // You have to define these by yourself
:     pEdit = new CEdit;
:     pEdit->Create (...);
:     m_arrMyControls.Add (pEdit);
:     break;
:   case CT_LIST:
:     pList = new CListBox;
:     pList->Create (...);
:     m_arrMyControls.Add (pList);
:     break;
:   case CT_BTN:
:     pBtn = new CButton;
:     pBtn->Create (...);
:     m_arrMyControls.Add (pBtn);
:     break;
: }
: 

:
: 3. When you finished at all with your page call 'delete' on every pointer in your array.
:
:

You normally add controls at run-time. So, there is no difference. Of course, keeping track of them is different when you don't know ahead of time how many and what you are going to have. However, that reduces the problem to any run-time allocation thing. Basically use an array, vector, list or some structure you can add the classes to.

"No Bad Religion song can make your life complete."
-No Direction, Bad Religion

It's really that easy, then? Many thanks, this is exactly what I needed to know. I can handle the run-time allocation and keeping track of things, it was just the semantics of creating them that I was concerned about. I was used to having MFC-generated wrappers for my controls, or using getDlgItem() using some compile-time defined identifier to reference compile-time defined resources (but then this could be due to the fact that I haven't done much at all in MFC yet, or in Win32 for that matter).
So, thanks for all the fish ;)

Greets,
Mark


: : : Hi,
: : : It is most likely possible to dynamically add controls (such as text/combo boxes or buttons) to a dialog window in C++ (using MFC), but I wouldn't know how. Can anyone tell me how to do this? The idea is to be able to have my proggie read some script or config file which specifies what controls should be present on each screen, etc. So, I would need to be able to create arbitrary controls at run-time as specified by the script. Any help would be appreciated.
: : :
: : : Greets,
: : : Mark
: : :
: : :
: : 1. You have to keep an array of pointers (CPtrArray) somewhere in your window/dialog class to hold these controls.
: :
: : 2. Now when reading a script you dynamically create the controls with 'new' and add these pointers into the array from step #1.
: : Do not forget to call 'Create()' method to create actual HWNDs for these controls:
: :

: : CButton* pBtn;
: : CEdit* pEdit;
: : CListBox* pList;
: : UINT typeFromScript;
: : 
: : // Parse the script and set the 'typeFromScript'
: : // You have to define some IDs because they should be used
: : // when you call 'Create()' - so you can receive notifications
: : // from your controls.
: : switch (typeFromScript) {
: :   case CT_EDIT: // You have to define these by yourself
: :     pEdit = new CEdit;
: :     pEdit->Create (...);
: :     m_arrMyControls.Add (pEdit);
: :     break;
: :   case CT_LIST:
: :     pList = new CListBox;
: :     pList->Create (...);
: :     m_arrMyControls.Add (pList);
: :     break;
: :   case CT_BTN:
: :     pBtn = new CButton;
: :     pBtn->Create (...);
: :     m_arrMyControls.Add (pBtn);
: :     break;
: : }
: : 

: :
: : 3. When you finished at all with your page call 'delete' on every pointer in your array.
: :
: :
:
: You normally add controls at run-time. So, there is no difference. Of course, keeping track of them is different when you don't know ahead of time how many and what you are going to have. However, that reduces the problem to any run-time allocation thing. Basically use an array, vector, list or some structure you can add the classes to.
:
: "No Bad Religion song can make your life complete."
: -No Direction, Bad Religion
:
:

Mark,

It is, probably, not my place to point out, but if you are trying to mimic the usual dialog boxes - why don't just use the dialog boxes? For every sutuation you can create a separate dialog box - it will be easier then to write scripts and add controls dynamically. If the case is that you do not now at all the contents of your dialog then you should implement it as you desire. However, can you bring an example of where you may be needing this functionality - when controls on a dialog box cannot be predicted in any way?

Cheers!

: Mark,
:
: It is, probably, not my place to point out, but if you are trying to mimic the usual dialog boxes - why don't just use the dialog boxes? For every sutuation you can create a separate dialog box - it will be easier then to write scripts and add controls dynamically. If the case is that you do not now at all the contents of your dialog then you should implement it as you desire. However, can you bring an example of where you may be needing this functionality - when controls on a dialog box cannot be predicted in any way?
:
: Cheers!
:
:
:

Hey, well that's a nice question. Have you ever heard of the game 'VGA Planets'? Or 'Romance of the Three Kingdoms'? Or, as another example, imagine a turn-based / play-by-email variant of Warcraft (assuming you know Warcraft). All of these would be examples of a turn-based strategy game, that take place on some world or universe (or for that matter it might as well be an island or an asteroid) where players have some types of units roaming around, building settlements at various locations on the map, intending to (most likely) expand their kindom/empire/whatever and rule over all of the in-game world, using instruments such as the military, diplomacy, trading, alliances, even contraband, etc.

Take all those games and they probably have more in common than would seem at first. That is, if you exclude the game graphics, and the game interface (which is largely dependent on the functionality specifics of any and all elements in the game).

A friend of mine and I, have the intention of writing some sort of game engine specifically for turn-based pbm games, but one where third parties can completely design their own game elements and mechanics. A hierarchical object structure, in an xml-like format, will define game data like what types of entities (such as army units, or trading alliances) can exist in the game, and what actions they can perform, and also what instances of these entities exist at any given turn, what they are doing, and their relations to other entities. All the while, a script (or several scripts) define the game mechanics, which specify exactly what happens, what does it mean for some entity to perform some actions, what is the result of it, etc.
Now, there are (asside from lack of code right now ;) two major gaps in the plan, which you might have guessed already from reading the second paragraph:

(1) What about the interface?
(2) What about the game-specific graphics?

So, number two is to far away yet to worry about it, by the way, don't we all know some kick-ass cg. artist, or a good royalty-free download site that can help out on this front? :)
And number one has just been solved. Of course it is possible to auto-generate an interface given the game-specific entity and action types (which, by the way, will be impossible to know in advance or be prepared for in any other way than throwing in the hype of Mr. 'dynamic' and Mrs. 'on-the-fly'). But it would be much nicer if game designers could specify for themselves what screens are available, and what will be on those screens, and where the automap should be placed. And so, we decided that the game interface design (and then, is there any other way, really?) should be part of the design for one specific game.

So, in a nutshell (chuckle), there is the answer to your inquiry. Was any of this making sense? By the way, ask me anything except 'when will this very cool game engine be finished', because probably it will never be finished, and if it will be then, who knows, maybe it's not so cool afterall... :P

Greets,
Mark