News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Tab Controls Without Dialog Boxes

Started by tomkane, October 01, 2006, 08:54:20 PM

Previous topic - Next topic

tomkane

Here's the next installment in my efforts to tame tab controls.

This time I'm working toward using tab controls without dialog boxes. The module that I'm attaching here is called "Tabber". It creates a tab control within a normal window. There are 3 tabs, each of which has its own separate window controls.

I want to point out the downside of doing this without dialogs: you have to manage the positioning of all the controls manually within the program, which is very time consuming. I thought I'd be smart and use the Borland Resource Workshop to lay out the controls in a dummy dialog box. But that didn't provide the full answer as sizes and positions would be off substantially by the time I had the program doing what I wanted it to do.

I don't think that the fact that the parameters for controls are hardcoded into the program is significantly inefficient as regards memory or speed. After all, they have to be stored, read from a table, and sent to Windows through calls anyway. The problem is mainly with regard to positioning.

The trick in coding the tabs is that one has to hide (e.g., SW_HIDE) all of the controls that are not supposed to be displayed when another tab is selected. When you switch tabs, you have to hide the previous tab's controls and show the next tab's. It works.

The most important pro for tab controls without dialogs is the flexibility in overall design. I was wracking my brain before I discovered this approach: could I use a massive dialog to be the front end of all the logic I anticipate using? But I decided that won't work because I have a requirement to present lots of complex data with an MDI interface.

Another upside of this approach, is that all of the data used for the window controls is stored globally in the module and there is no need to make system calls to access the fields of data within the dialog. Of course, that is the flipside of the coin -- all the work that has to be done to manage the controls.

After developing this small module, I don't think that controls like radio buttons, check boxes, or maybe even simple buttons will do well with this approach. I really expect that controls like multiline edits, list boxes, treeviews, and listviews will be more desirable. This is more of a feeling, however, but I think that computations can be made on-the-fly when the user resizes the window.

In my next iteration, I will be attempting to utilize the split bar functionality that Ewayne Wagner programmed in the \exampl06\treedemo example. That will give a lot of user flexibility for viewing various types of data. That, plus, I want to get it all to work in MDI child windows that have separate menuing functionality.

The bottom line is that -- by using the non-dialog tab controls -- I've enabled myself to present the desired interfaces to end users. I will still use dialog boxes wherever they make sense, however.

This was just a test. I haven't used it in a real, substantial application yet. Wish me luck!

[attachment deleted by admin]

PBrennick

tomkane,
Very nice.  Keep us posted on how you make out with the application development.  I can see where this method has possibilities.

Paul
The GeneSys Project is available from:
The Repository or My crappy website