Tab Control not allowed in QuickWin??

[Intel_C_Intel]

According to the documentation of the tab control, one must "call DLGMODELESS for each of the Tab dialog boxes". Since DLGMODELESS is not compatible with QuickWin, it sounds as if the tab control is also incompatible. Is that correct? Or is this use of DLGMODELESS a special case, perhaps, because it doesn't really display the dialog boxes?

I did get a tab control dialog example to work in QuickWin, but I had to do almost all navigation/selection with the mouse. Accelerator keys didn't seem to work at all, and the tab key focused only on the tab caption. I placed the Cancel and OK buttons on the parent dialog, and they seemed to work okay.

Am I wasting my time? Am I likely to encounter even more problems if I incorporate this into a larger project?

[Intel_C_Intel]

I'm sorry. This was discussed in December.

[kvrichardson]

Not sure if I understand what you're trying to do with tab control, but here's what I know.....Open any dialog box in the resource editor and hit ctl-D. That lets you set the order of the controls accessed by the tab key. If there are controls you don't want accessed by the tab key, open those controls and de-select "tab".

[Intel_C_Intel]

No, I'm using the tab control, which "...is like the dividers in a notebook...." (online help). Like the ShowFont example supplied with CVF, I have three tabs on the tab control, but, unlike ShowFont, I have a QuickWin project, and I have multiple controls on the child dialogs displayed on the tabs. I followed the usual practice of placing an ampersand in the caption of the static text that is immediately prior to an edit box in terms of tab order. However, accelerator keys do not function, and I cannot tab from one edit box to another. I followed ShowFont's technique of setting focus to a particular control whenever a DLG_SELCHANGE event occurs, and that works. Pressing the tab key, though, never places focus on a different edit box but only on the tab's caption; there left- and right-arrow keys will change to a different tab.

I discovered there is a way to enable the usual tab-key capability, but it comes with a price. Select each child dialog in turn and check "Control" on the "More Styles" tab of the dialog properties dialog. Then the user can tab from one edit box (or other control) to the next. Eventually the focus reaches the tab caption and no further tabbing is possible. Accelerator keys still don't work, but at least there is enough keyboard functionality to use the dialog without a mouse.

I mentioned a price. It's steep: any Alt-key combination causes the program to lock up!

I'm using CVF 6.5.0 under WinNT 4(SP6). I'd appreciate any suggestions.

[Intel_C_Intel]

The tabbing issue in a tab control is a complicated one. The basic
reason is this: the Windows code does not handle nested dialog boxes
very well. You have nested dialog boxes whenever you use a tab control
in a dialog box. The problem area is all of the special dialog box
behavior that is implemented by the Windows API IsDialogMessage.
This includes things like tabbing, default button activation, etc.

I'll explain 2 items that Windows uses in its nested dialog box
"solution".

The first item is the Windows API IsDialogMessage. You need to call
IsDialogMessage for the appropriate dialog box(es) in order to get
the dialog box behavior. When using a tab control, this means calling
IsDialogMessage on the active tab dialog box and then on the main dialog
box. The CVF DlgIsDlgMessage routine is the one that calls the
IsDialogMessage API. I think the CVF Dialog procedures could do more
for tab controls in this area and this in on our list for
future consideration. But, for now, part of the solution to your
problem is to keep track of the current tab dialog box and call
DlgIsDlgMessage on it. This means that you can't use DlgModal, because
with DlgModal you do not have control of the message loop, so there is
no where for you to make the call. You need to use DlgModeless.
Fortunately, it is easy to make a modeless dialog box act like a modal
one - you simply "disable" the parent window while the modeless dialog
box is active - e.g., ok = EnableWindow(ghwndMain, .FALSE.)

The second item is the "ControlParent" property that you can set on a
dialog box - see the Dialog properties, Extended styles. The
"ControlParent" property is supposed to tell Windows that the dialog box
is nested, and then Windows is "supposed" to be able to handle dialog
box behavior across the nested dialog boxes. Unfortunately, this
support is very "fragile".
The problem is that Windows can easily get itself into an infinite loop
when searching for the next control to tab to, the control that should
be the default button, etc.

Not using "ControlParent" leaves a few problems. Windows won't
automatically tab "into" or "out of" the nested dialog box, and
key presses when focus is in the tab dialog won't implement the
dialog box default button behavior. There are work-arounds
for 2 of these problems.

For tab "into", when the user selects a different tab, you can add a
call to the Windows SetFocus API to set the keyboard focus to the first
control in the tab dialog. I don't know of any way to fix the tab "out
of" problem. Once focus is inside a tab dialog, it will remain there,
until the user clicks on another tab or one of the controls in the
main dialog box.

For the default button behavior, you can add code to the message loop to
look for key presses of "Return" and "Escape". You can activate the
OK or Cancel button in this case, as the normal dialog box behavior
would.

Leo