Designing Versatile Add/Edit Forms & Pages

This is more of an opinion question than a "need help" type question.  I'm new to the visual programming world and I'm beginning to learn to work with classes ... subclassing, etc.

I've noticed that Microsoft uses page frames very heavily in their applications.  Usually, they'll have a page frame with multiple pages with editable fields on each page.  They'll have one cancel and one apply button on the page frame that applies to all pages.  Each page may or may not have it's own add, remove or properties buttons.

In designing apps, is their a tendancy to create a custom page frame that includes an apply, cancel and quit button and then just hide them if you don't need them, or to create a button group of cancel, apply and quit buttons and place that button group as needed or do most folks just add those buttons individually as they need them?

If there is someone who has developed a method of implementing a "default" set of cancel, apply, quit buttons, I'd be interested in hearing how you implement a default set of buttons to work with a page frame where each page may be dealing with a different table.

I'd be interested in getting a few different opinions on this so I'm willing to give out points to more than one xpert (if I'm able to).

Thanks for the help.

Who is Participating?
PatrickVDConnect With a Mentor Commented:
Hi Rodd,

I think I understand what you mean when talking about the Page frames that MS uses very often...

As far as I can see, this is always the case when you are editing properties or preferences in a MS application

This is mainly how I do in my applications too... I think its a good approach for editing settings/preferences. As a matter of fact, its even quite normal that this type of dialogs include only one 'OK','Apply' and 'Cancel' button (at least in my opinion). As one might say, you apply all the property/preference changes or none of them... that's what I can understand behind the fact that only 1 set of these buttons are available....

The main advantage of this kind of approach is that it is easely extendable. If tomorrow you make a new version of your app, and you have new settings/preferences, you simply add a new tab/frame to the dialog and you don't need to implement new form handling and so on.. For the user of your application, it will be easier to find his way around in the new version, because the way of changing settings remains the same throughout the different versions...
It also allows you to group the different settings of the same category together in the same page/tab, which also will look a more natural approach for the end user....

Now, referring to your remark, that each page might be handling a different table... As far as my implementations are done, I try to encapsulate the data storage into a separate classmodule. By doing so, I can manage the state of all the settings into the same class (even if they manage different tables) because the REAL data update will only happen if the user presses 'Apply' or 'OK'. At that moment this encapsulating class will start writing the data to the different tables if needed (most often by using other instances of data classes that encapsulate the data access each to a particular table).

I hope my point of vue is of any help to you...


rharrAuthor Commented:
Adjusted points to 150
OK ... this is just a matter of opinion I am sure.  I have a form that I created a while back that uses a similiar technique (frmTemp - save name), a generic form with a few built in routines.

This form includes an OK, Cancel, and Help button, one picture box with an index of 1 (within a TabStrip Control for navigation purposes).  This way, I can copy and paste the picture box as many times as needed (within the TabStrip box) to create "pages" within this form.  Ofcourse, the Picture boxes contain frames, checkboxes, radio buttons - anything that is needed.

Just have the tabstrip hide and show the various picture boxes,by their Index number, to page through the options or what have you.  With one Global variable (I set equal to the picture box index) my generic buttons can now use a Select Case statement to perform various task (pertaining to the picture box index).

This is just one of many ways I am sure to create page frames.  I hope this becomes a little useful for you.  Good Luck!
Never miss a deadline with

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

rharrAuthor Commented:
Thanks Patrick,

I understood you great until the last paragraph.  I didn't quite follow your implementation of a class module that deals with "encapsulating the data access with each particular table".  Could you give me a give me a bit of an example of what this class may be like?

Thanks, Rodd
Hi Rodd,

Let me try to make it clear to you...I problably didn't use the right way to express myself (english isn't my mother tongue, but i do my best!)

What I meant is that I never code the data storage VB code (ADO or something else to get the data in the database or other storage medium like Registry for example)  in the form itself.
This is always managed by a seperate class module. I actually program only UI behaviour code in the forms and everything else is encapsulated in the 'data' classmodules. This often comes to 1 data class = 1 data table.

That's actually what I meant. I hope I made it clear this way.



rharrAuthor Commented:
Thanks Patrick!

That cleared it up nicely ... and by the way, you're English was just fine!  8?)

All Courses

From novice to tech pro — start learning today.