Many Forms vs. one tabbed form. (1 Viewer)

[Monardo]

Hello everybody.

I almost never use Tab Control on a form, as I always thought it was not worth the "trouble", but today someone said that Access does not like having too many forms.

So basically it made me think:
Is it better to use for instance 10 separate forms or 1 form with 10 tabs. Or maybe something in between. What are your thoughts?

 

[GPGeorge]

I'm not sure why someone would flatly start that " Access does not like having too many forms". Perhaps there's more behind that than appears on the surface, but there's really no such thing in a technical sense. Perhaps they were speaking of a particular scenario?

In an event, the choice probably has more to do with whether the forms are part of a set of related child functions and need to be embedded into a master form for that reason.

 

[theDBguy]

And, even if you use a Tab Control, it could mean each tab will contain separate forms anyway.

 

[Monardo]

I'm not sure why someone would flatly start that " Access does not like having too many forms". Perhaps there's more behind that than appears on the surface, but there's really no such thing in a technical sense. Perhaps they were speaking of a particular scenario?

In an event, the choice probably has more to do with whether the forms are part of a set of related child functions and need to be embedded into a master form for that reason.

I totally agree, it made no sense. It was said as a comment to a form with 7 or 8 tabs.

 

[SHANEMAC51]

So basically it made me think:
Is it better to use for instance 10 separate forms or 1 form with 10 tabs. Or maybe something in between. What are your thoughts?

if the forms on the tabs have their own data source, I use the form call by a button (or a line in the list to save space on the screen) in a separate window

I use tabs only if there are too many fields (perhaps the table is not normalized) and the fields do not fit into the screen

 

[Uncle Gizmo]

Many people fall into the trap of creating multiple forms unnecessarily.

I call them "Cookie-Cutter Forms"

This is where you have one original form, and you want it to do something slightly differently. You make a copy and make a minor alteration to it. Now you have two forms! Carry on like this and you can end up with 20 or 30 forms which are basically the same.

The solution is to make a minor change to the form with VBA. This approach can reduce the number of forms from 20 or 30 to 2 or 3.

 

[Pat Hartman]

The reference to too many forms on a form with a tab control is valid. When the form opens, all those forms must load and their data retrieved. So, at some point, your form may become slow.

The navigation form was an attempt to get around this problem. The technique it uses is that it actually uses only ONE subform control and as you choose a tab, the subform for that tab gets loaded into the only subform control. This method is good and bad. On the one hand, it is more efficient since you only need to load the forms you are going to use but on the other hand, you have to load them multiple times if you constantly switch tabs. The other downside is that you can never refer from one subform to another or from the main form to a subform unless you know which subform is actually loaded.

When you make your own tab form, you get to use whatever technique makes sense for your application and even combine them by having an actual subform control on each tab but leaving the less commonly used ones unloaded until the user chooses the tab that will show the unloaded form so you load it on demand if it isn't already loaded and once it is loaded, you can leave it there so you only load it once.

Using tabs to organize fields when a form has too many, is a good solution. Just make sure that all required fields are on the first form and also that your table is properly normalized because properly normalized tables rarely need to employ this technique. If I do this, I put the required fields at the top part of the form so they are always visible. Then the less important or less frequently viewsd on other tabs.

 

[GPGeorge]

The reference to too many forms on a form with a tab control is valid. When the form opens, all those forms must load and their data retrieved. So, at some point, your form may become slow.

The navigation form was an attempt to get around this problem. The technique it uses is that it actually uses only ONE subform control and as you choose a tab, the subform for that tab gets loaded into the only subform control. This method is good and bad. On the one hand, it is more efficient since you only need to load the forms you are going to use but on the other hand, you have to load them multiple times if you constantly switch tabs. The other downside is that you can never refer from one subform to another or from the main form to a subform unless you know which subform is actually loaded.

When you make your own tab form, you get to use whatever technique makes sense for your application and even combine them by having an actual subform control on each tab but leaving the less commonly used ones unloaded until the user chooses the tab that will show the unloaded form so you load it on demand if it isn't already loaded and once it is loaded, you can leave it there so you only load it once.

Using tabs to organize fields when a form has too many, is a good solution. Just make sure that all required fields are on the first form and also that your table is properly normalized because properly normalized tables rarely need to employ this technique. If I do this, I put the required fields at the top part of the form so they are always visible. Then the less important or less frequently viewsd on other tabs.

In cases where there are a lot (more than two) tabs with separate subforms, I like to use the "lazy load" approach. Only one subform control is loaded at a time; the others have the subform removed from the subform control when they are not used. This is controlled when you select a tab on the tabform control. The code loads the selected subform into its subform control and removes all others.

I have most effectively used this when the BE is a remote SQL Azure database, where the data is coming down that long skinny wire from "the cloud".

 

[gemma-the-husky]

If you open a lot of forms from the same data source (table), and edit more than one of them, you will get the "another user changed the record" issue, where you are the other user. That's one reason to have a tabbed control.

 

[CJ_London]

From a user navigation perspective, I like to keep all navigation visible on one form (and as short as possible) and use a single subform to display whatever is requested by the user - very much like a web browser. That subform may in turn have additional navigation options and subforms. For example users selects 'customers' this will then assign a subform which typically will list the actions the user can undertake and /or a search facility - which in turn potentially opens further subforms. At all times the full navigation path is always visible.

There is some functionality - a user can select wherever they are as a 'favourite' and it will be added to the main navigation - if on a particular customer record they can get back to that record with one click of a button from the main navigation form. Or it might be a process they have to undertake on a regular basis which would otherwise take a lot of clicks to get to. Most of this is managed in the same process of maintaining an audit trail.

Occasionally I will use popups so users do not need to navigate to a different form, do something then return. For example a user in invoicing needs to add a new customer - the customer form would open as a popup

Another functionality is the user can create a separate instance of the subform as a popup - effectively lifting it off the main form. This is useful when a user needs to visually compare records side by side or a result needs to be updated without leaving the form.