10

Alright so first im coding in C using the win32 api, no mfc, no .net, no wxwidgets. I've created a window with the WC_TABCONTROL class, and have added tabs to it, everything works fine except... I need to have content in each tab, I got the impression from msdn that I needed to create a dialog for each page, and then load the dialog when the user selects a tab. Only problem with this is my main window isnt a dialog, so making the dialog box for the tab fit perfectly is not working too good.

So I'm wondering if there's a better way to do this? I thought about just hiding and showing different controls per tab but that doesn't seem like a good idea.

What I'd like is when my application starts it will resize the window and the tab control to the minimal size needed to fit all the tabs (3-4 tabs), and the window isn't going to be resizable which I guess simplifies things a little bit. I did this by following the example on msdn (Loading each dialog box into memory, looping thru each one and setting a RECT to the minimal size needed then resizing everything), problem is that the size is in dialog box units and I can't convert it to pixels because I don't have a HWND to the dialog box yet.

Basically my question is what is the best way to manage controls on a window with a tab control. So if I have a tab control and the user changes from tab1 to tab2, I want different controls to be displayed to the user.

CRABOLO
  • 8,605
  • 39
  • 41
  • 68
Josh
  • 6,046
  • 11
  • 52
  • 83
  • 5
    Upvoted for my fellow "no mfc, no .net, no wxwidgets" brother. :( – Colen May 18 '11 at 18:08
  • 8
    My reason for not using mfc or .net or wxwidgets is one: learning purposes, and the win32 api fascinates me. And i've always liked doing things a little lower level. – Josh May 18 '11 at 19:08

1 Answers1

5

The basic idea that MSDN is getting at is to have the controls for each tab within their own HWND. The benefit of this is that you can hide/show all the controls within a HWND by hiding/showing that parent HWND. This means that going from one tab to another is just a case of hiding one container HWND, and showing another, which is simpler and more elegant than having to hide/show groups of controls. (It also keeps the dialog handler code for each pane separate, which is usually what you want.) Both approaches are allowed, though: it's often more convenient to create a dialog, but you are not required to.

These container HWNDs don't have to be dialogs, but using a dialog means that windows will populate the contents from a .rc file for you and handle keyboard tabbing automatically. If you create your own HWND, you'll have to do this yourself. You could take a hybrid approach: start off with a dialog, but add your own controls in the WM_INITDIALOG handler if you need to, and even handle WM_SIZE to do custom layout so that the controls fit better.

If you go the create-your-own-HWND route, look up IsDialogMessage() for a simple way to add keyboard tabbing support to your own HWND; and also check out the WS_EX_CONTROLPARENT style so that tabbing between the tabs themselves and the controls in the container HWND work.

Re: "problem is that the size is in dialog box units and i cant convert it to pixels because i dont have a HWND to the dialog box yet." - you may be able to use CreateDialog to create the dialog as invisible - omit WS_VISIBLE from the .rc file - then you can measure/resize as appropriate before you show it.

BrendanMcK
  • 14,252
  • 45
  • 54
  • I thought about using CreateDialog to create each dialog and check the size, only problem is that involves creating about 4 dialogs just to get the application running and id prefer to create them as-needed, so if theres any way I can check the size of each one without actually creating them? That would solve my problems :) – Josh May 18 '11 at 22:17
  • 1
    Dialogs may be relatively cheap to instantiate - relative to end-user perception of time anyhow. (If you're populating them with information from slow sources, then sure, delay the population.) My 2c: go ahead an try it the easy way first, and see if it's fast enough. If it's fast enough, then you're done, move on to next problem. Only spend the time adding the extra complexity to measure without creating if you're sure it's needed to make a necessary difference. (General dev rule: don't optimize prematurely: dev time is a valuable resource, use it where it makes most difference.) – BrendanMcK May 19 '11 at 07:28