"Dynamic" Dialog boxes

[Gyannea]

Is it possible to make dialog boxes that have different controls within them depending upon the situation? In this case, many of the controls would be the same, but a set of them would change.

The easy solution would be to create a dialog within a dialog calling the different dialogs depending upon the situation, but I would like to avoid that as I am trying to make a situation where as little information is hidden as posible.

IN this case, I have a radio controller, both VHF and HF. Most of the features are the same, but the frequencies and channels are not. So in the VHF case I would like the VHF frequency options/controls to appear in that corner of the dialog box instead of the HF options/controls.

Any refs?

THanks,

Brian

[RussG1]

What do you mean by "hidden"?

It seems your choices are:

Use 1 dialog with all controls for both options, and hide the controls not being used at the time (will probably need to repostiion the controls as well when you hide/show the other controls).

Use 2 completely different dialog's.

Use 2 different dialogs (that contain only the controls that are not shared) that are embedded within the main dialog (3 dialogs total), showing the appropriate one depending on whether VHF or HF is being used (I think this is the method you mentioned).

Create all the controls programmatically/dynamically.

Use a type of control that is compatible with both, and populate the control's programmatically depending on which option is in use. i.e. You mentioned that only the Channel's and Frequencies are different. How are you displaying these channels/frequencies? Can it be changed to use a common control (i.e. List control or something), that can be populated programmatically depending on options in use?

Personally I would try and use that last option.
i.e. Use a List Control in report view mode, with a column for channels and a column that shows the frequency for each channel, etc, and change the channel/frequency when an item is selected (to the channel/frequency selected). You can populate the items in the control dynamically depending on which option is selected (VHF or HF, etc).

[Gyannea]

By "not hidden" I mean I don't want the user to have to open a menu or dialog box within the dialog box to see/select further options. Many items are dependent upon other items/selections, so it is good for the user to see everything all at once. For example, selecting one item may force changes in another or disable other controls, so it is good to see that all up front just to know what caused it.

I can't use the last option since the channel and frequency structure between the VHF amd HF units are totally unrelated; otherwise that's what I would have done.

What I didn't think about was "hiding" the controls. I take it you mean the "VISIBLE" style. It would be a real pain in the butt in the dialog editor as one would have two sets of controls superposed on top of one another but in the actual program only one set of controls would be visible and functioning.

It's going to be a lot of bookkeeping but at least it looks possible! You can have two controls on top of one another, correct? And if one is made invisible, then the user cannot access it (it would be like it is disabled), correct? Or is that wrong?

Thanks,

Brian

[Paul McKenzie]

Yes, you can overlay controls on top of each other, and in the WM_INITDIALOG message, hide or show the controls that you want. The problem is that as you stated, it is difficult to use the dialog editor for these types of scenarios.

Regards,

Paul McKenzie

[Sam Hobbs]

As I understand the requirements, you have a set of controls for a VHF and a set of controls for a HF. Will the controls for VHF always be the same when showing controls for VHF and will the controls for HF always be the same when showing controls for HF? If so, then you can use a child dialogs. It will be much easier to show/hide and enable/disable a couple of child dialogs instead of coding each control separately.

[RussG1]

I was thinking the same thing.
I am not sure how having all the controls on one dialog and showing/hiding them, is any different from using 2 different child dialogs using your definition of "hidden". (and I agree with Sam that using 2 child dialogs should be easier).

Unless your reasoning is for layout considerations. i.e. Maybe you have a control that is common for both settings mixed in with control's that are only for 1 setting, and using seperate dialogs, would mess up that layout.

[Gyannea]

THis sounds good; but I think I am a little ignorant when it comes to "child dialogs". I do have buttons in a dialog box that when pressed bring up dialog boxes, and if that's what a "child" dialog box is, then it's not what I need.

Just to clarify why I want to have all the options "exposed" in this particular dialog box is that, for example, one part of the dialog box contains a set of radio buttons that give the priority of the call (routine, safety, urgent, distress) and another set gives the possible addresses of a call (individual, a geographic region, a group of stations, everyone). Now the powers that be have decided that calls of certain priority are only allowed certain addressing modes. So if you select a given priority, certain addressing options 'gray out', and vice versa. Now there are MANY of these cross influences amongst many of the parameters. SO many that if these selections were done in sub dialogs or menus, you would often have a hard time seeing what caused what. That's why I want to keep it all "open", so one can see the consequences of any selections.

So what I am hoping is that in this dialog box when I have a VHF radio, in that corner where I have a bunch of controls that select channels and frequencies, that set of controls which select the VHF channels and frequencies will appear. When I have an HF radio, another (and quite different) set of controls that control the HF channels, simplex/duplex, and frequencies will appear.

If a "child" dialog allows one to simply go from a contained set of controls within a parent dialog without having to open the dialog box, that's EXACTLY what I need. I suppose there must be a "child" option in the dialog editor and someway to identify the parent or does one have to do that by directly editing the resource script file?

Thanks greatly!

Brian

[RussG1]

It sounds like you want to use modeless dialogs, embedded in your main window. These would move along with the main window (they would not prevent you from accessing other control's on your main window, like a modal dialog would), can look any way you want them too (i.e no border, no title bar, etc), and can be hidden or shown as needed. It would be just like hiding/showing a whole group of controls at once, instead of doing it one at a time for each control.

[Sam Hobbs]

If I understand what you are trying to do, then what you can do is to do what is done for tab controls. I did not suggest a tab control simply because you seem to need to seleted the child dialog using criteria other than simply pressing a button as in a tab control. However most of what is done for a tab control is useful here too probably. A tab control basicaly just consists of a set of buttons (the tabs) and a viewing (display?) area. We provide the content that goes into the viewing area, and usualy the content is modeless dialogs that are children of the dialog.

I have a couple of samples but they use MFC so I did not suggest them. In case they help, look at my Creating Tab Controls Using CTabCtrl (http://simplesamples.info/MFC/CTabCtrl.php) and my Child Dialogs (http://simplesamples.info/MFC/ChildDialogs.php). Also the Platform SDK Tab Control (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/CommCtls/Tab/Tab.asp) sample might help.

[Gyannea]

I already use modeless dialog boxes and I don't want to use buttons as in a tab control to bring up dialogs (that's the only way I know how to do it at this stage and I am trying to avoid that). But another thing I didn't think of was to use a set of modeless borderless dialog boxes within a dialog box all using the same dialog callback function. Hopefully the control states (enabled/disabled) within each of these dialog boxes will be able to be displayed on the fly (when I change a control in the main dialog box that effects a control in another that the effect will be immediately visible in the other.

By the way, what is a "child" dialog box? I'll check out your "child dialog" stuff...hope its not MFC! (My Petzold doesn't offer too much on this subject.)

Brian

[RussG1]

Attached is a quick example of using 2 modeless child dialogs within a main modal dialog.

Each child dialog will be shown depending on which radio button is selected. The controls on the child dialogs do not do anything, as I just included them as an example to show some controls and to differentiate between the 2 dialogs, etc.

It is just a quick example you can look at to see if you want to use a similar method, etc.

[Sam Hobbs]

I am not sure if it will work to use one procedure for multiple dialog boxes, but otherwise I think you are headed in the right direction.

Whether Petzold describes child dialog boxes or not, most of what he says about child windows would be relevant. So probably he says little or nothing about child dialog boxes because there is not much more to say. Note that the controls in a dialog are children of the dialog.

The advantage of using child dialog boxes is that you can show/hide and enable/disable just the child dialog boxes without having to do that for the controls in them. Did you get that?

[RussG1]

Child just means it was created using the WS_CHILD window style, as should be any controls on a dialog. If you look at the properties for a Dialog in the resource editor, you will see an option for Style, which can be changed to Child to specify that the dialog should use the WS_CHILD window style.

[Sam Hobbs]

As for how to create a child window, there is not much more required than specifying the WS_CHILD style. Note however that a child must have a parent, right?

However the affect of making a window a child has many consequences. For example, what is relevant here, is that a child moves with it's parent and a child's position is relative to it's parent (in the parent's client area). Also relevant here is that, as I said, you can show/hide and enable/disable just the child dialog boxes without having to do that for the controls in them

[Gyannea]

This is great. The child dialogs will do exactly what I want and need. Wish I had known about them earlier!

Brian

[RussG1]

You might also want to know about the DS_CONTROL style (which I used with the child dialogs in the example I posted).

This style is set, if you choose TRUE for the "Control" property in the dialog editor.

This style is described as follows:
Creates a dialog box that works well as a child window of another dialog box, much like a page in a property sheet. This style allows the user to tab among the control windows of a child dialog box, use its accelerator keys, and so on.

BTW:
I am not sure what all the differences are between the DS_CONTROL style and the WS_EX_CONTROLPARENT style (which has a similair description), but using the DS_CONTROL style does add the WS_EX_CONTROLPARENT style to the window as well when it is created (confirmed using SPY++) even though this is not apparent at design time in the resource editor.