Tab Control in existing dialog box

[acerunner316]

it is called from what is now a child tab window. The code worked fine as the main dialog window until i started using tabs.

[acerunner316]

Another question, since the two tabs does very similar tasks and functions, is it possible to use the same dialog class for both tabs, but different resource dialog (ie IDD_TAB1 and IDD_TAB2 both associated with CTabDlg)? The layout will be different, but I will be reusing most of the same functions.

[Mark Salsbery]

Does this work? CRect MainDialogRect, LoadDialogRect; GetParent()->GetClientRect(&MainDialogRect); pLoadingDlg->GetWindowRect(&LoadDialogRect); pLoadingDlg->MoveWindow((MainDialogRect.Width() - LoadDialogRect.Width()) / 2, (MainDialogRect.Height() - LoadDialogRect.Height()) / 2, LoadDialogRect.Width(), LoadDialogRect.Height());

[Mark Salsbery]

Yes it's possible. You'll need to create with the appropriate resource ID. You can also use a common base class containing the code for the controls they have in common and derive 2 classes, each with whatever code they need for the unique parts of the dialogs.

[Mark Salsbery]

Argg sorry - try this :) CRect MainDialogRect, LoadDialogRect; GetWindowRect(&MainDialogRect); ::MapWindowPoints(0, *this, (LPPOINT)&MainDialogRect, 2); pLoadingDlg->GetWindowRect(&LoadDialogRect); pLoadingDlg->MoveWindow((MainDialogRect.Width() - LoadDialogRect.Width()) / 2, (MainDialogRect.Height() - LoadDialogRect.Height()) / 2, LoadDialogRect.Width(), LoadDialogRect.Height()); Tab control doesn't really have a useful client rect so I've taken it's window rect (relative to the screen) and mapped it to be relative to itself. I think that will work...

[Mark Salsbery]

:laugh: Now that I think about it more, the MapWindowPoints() isn't necessary since you only need the size of the tabs control, not it's position. You can probably eliminate that call. The important part is using GetWindowRect instead of GetClientRect.

[acerunner316]

I still get the same result with that code. But that gave me an idea. Here's what I did to fix it. CRect MainDialogRect, LoadDialogRect; GetParent()->GetWindowRect(&MainDialogRect); pLoadingDlg->GetWindowRect(&LoadDialogRect); pLoadingDlg->MoveWindow(MainDialogRect.left + ((MainDialogRect.Width() - LoadDialogRect.Width()) / 2), MainDialogRect.top + ((MainDialogRect.Height() - LoadDialogRect.Height()) / 2), LoadDialogRect.Width(), LoadDialogRect.Height()); I found that I was always getting the correct coordinates, just relative to the wrong point (screen origin vs window origin). So I added the location of the main window to the coordinates.

[Mark Salsbery]

:laugh: Whatever works. Seems weird (obviously, or you would't have asked about it in the first place) that you'd get screen-relative coordinates from GetClientRect()...

[acerunner316]

When I create a new dialog in resource editor and I use class wizard to assign an existing class to it, I get a warning that the dialog class definition is already using another resource. It asks if I want to change it to the new resource, but I don't want to change it, I want it to use both resource... Is this the correct way to do it? The 2 derived classes sounds like the best solution. I would have to remap all the controls from the existing tab window though. It will take longer, but I think in the long run, this is the better option.

[Mark Salsbery]

acerunner316 wrote:

Is this the correct way to do it?

Yeah I didn't think about how the class wizard would react :) I guess some hand-coding/rearranging will be necessary.

acerunner316 wrote:

I would have to remap all the controls from the existing tab window though

If you choose to go that route, use the class with the most code already in it. Copy the cpp and h files and rename to the base class name or whatever. In the files find/replace all instances of the old class name with the new name. That'll save much work.

[acerunner316]

Yeah that IS very unusual. Maybe something to do with the fact that it's a tab window. Who knows what actually goes on in the GetClientRect() function. Maybe you do, but I sure don't. :laugh: You are clearly much more experienced in VC++ than me.

[Mark Salsbery]

acerunner316 wrote:

Maybe you do, but I sure don't.

Not me. :) I dug in my existing code and saw I was mapping the window rect points like that second code I posted (in my case I handle the tab control and all the associated tab windows from the tab's parent window class so it's a little different). Regardless, the MoveWindow call should move the child window relative to it's parent's client area. :wtf: Beats me!

[acerunner316]

The class wizard doesn't seem to allow creating a derived class from a derived class. In the Add New Class dialog box, there is no selection for user defined classes, just the standard Windows classes.

[Mark Salsbery]

That has to be changed by hand as far as I know. I usually derive from the known (by the class wizard) class (CDialog) and then change all the CDialog to CMyDialog. This is way easier after all the controls and control message handlers have been added using the wizard. Later, if controls are added or removed I just do it by hand, since there's already code there to copy from. It's a fact of life with an advanced UI layout :) Someday the wizards will learn from the way we do things and adapt....I hope!