Is a form with lots of tabs dangerous? (1 Viewer)

[ascaife]

Hi Guys,

I'm setting up a form that requires quite a lot of information.

Here's the rundown:

Student Information

Tab 1 (Contact Info) = 27 fields (9 of which are combo)
Tab 2 (Personal Details) = 20 fileds (10 combo), 1 option group, 7 option buttons
Tab 3 (Enrolment Records) = courses subform with 30 fields mostly combo boxes + another subform of 9 combo fields within it displaying units relating to the course and student status for each unit
Tab 4 (Contact Log) = Subform with contact history notes - 2 combo's and 1 text field

My question is, am I asking for trouble with this much information on one form? Is the form going to become really slow once we start filling it with data?

If so, can anyone advise a suitable alternative.

Thanks,

Andrew

 

[MarkK]

What you can do here is put ONE subform control and ONE transparent tab control on your form. Size the subform so it looks like its on a tab, and as you move thru your tab pages it looks like there's a subform control on every page. Finally, when your user changes tabs, your code changes the SourceObject property of the subform control, which changes the subform.
Make a subform for each of your categories of information, contact, contact log, personal, enrollment.
Simple, tidy, efficient.

 

[boblarson]

I hope tabs 1, 2, and 3 don't have data all from one table. If so, that is a normalization nightmare that needs to be addressed.

 

[ascaife]

Thanks for the answer. I'm afraid I don't quite understand what you mean. Do I create a separate form for each page, then paste them all onto one form layering them on top of one another?

Bob: Tabs 1 & 2 have data from the same table. I figured that since both tabs contain contact information and field sizes are relatively small, I wouldn't need to normalise - is that an issue?

Of course, Enrolments records and contact logs have their own tables.

 

[Galaxiom]

Having multiple controls bound to the same fields of the same table just isn't done. There would be a conflict between the values in the controls when the record was updated. You could place the common information on the main form and the rest in the subform.

You make a one form for each "tab" and display one of them in the subform control. The code for the tab control click triggers the Source Object of the subform control to change to the appropriate subform.

The subform is linked to the main form by the subform control Master and Child Links.

 

[ascaife]

Sorry I must not have explained correctly. When I said tabs 1 and 2 where both contact information, I didn't mean they were the same fields, just that there were too many fields for one tab so I used a second.

I'm okay with setting up the tabs normally with master and child fields, but lagbolt seems to be suggesting a different setup that I don't really understand.

 

[Galaxiom]

Tab controls are really just formatting controls so they don't intrinsically have Master Child Link properties. Subform controls have these.

Lagbolt's suggestion is to avoid having so many controls on the form and so many fields in the Record Source. The main form Record Source only needs the StudentID and any fields you would want to search by.

The tab control is on the main form. Rather than transparent which is not a property of a tab control I expect Lagbolt meant to set the tab control small enough to show just its tabs.

Directly underneath this place a subform control. These controls have a Source Object property. In the On click event of each tab write code to change this property of the subform control to the appropriate form object.

This way each subform has a limited number of fields in its record source so everything is not loaded at once. Yet it looks like a big tabbed main form. Remove all the extraneous stuff like borders and record selectors from the subform objects.

 

[ascaife]

Awesome, that makes perfect sense. Thanks to both of you guys.

 

[gemma-the-husky]

generally a tab control is a good idea

look at the tool options in this or excel

it groups together sets of associated settings, to make it an easier experience for the user. If your data has many fields, its a good way of showing lots of info

eg - with a system that has

customer
orders
order details
delivery data

any of these records could easily have 50 fields or more. you dont necessarily need ot see all of them - but with the delivery record in particular, you might use a tab control to show selected data on different tabs.

and its not slow - if it all comes from a bound source its quick.

i even use a tabbed form to show daily/weekly stats for reporting puroposes. i have dozens of separate queries to retrieve the data, and then show them all on a tabbed form - to let the users extract the KPIs they need.

its all done with dcounts and dlookups - and it still opens real fast, despite what people here say about these functions. and even if it takes a few secs, its worth it, because the users get all their info simply, from 1 place.

 

[Galaxiom]

Dave is correct. I was basically just clarifying what lagbolt described. It isn't really necessary in the situation described in the original question.

This dynamic subform technique would only be used when there are huge numbers of controls bound to many tables with vast numbers of records.

It can speed up the loading of the form because it only loads part of the data at a time. It isn't usually a problem on fast computers with loads of memory on modern high speed networks.

 

[MarkK]

Thanks Galaxiom for expanding on what I was saying.
And check out the tab control's 'back style' property. If you set this to Transparent, you can see through the control to objects that are 'under' it in the z-order.
I believe there is a noticeable performance improvement, particularly in subforms that represent data from larger tables, to loading the subforms after the main form opens. Notice that a subform that is present on the main form in design view runs it's Open and Load events BEFORE the parent form. This being the case any subform present on the main form in design view will load ALL it's data first, then wait for the parent to load, and then requery its data source to only return records satisfying the LinkMaster and LinkChildField. Now add a few subforms to your form and you can definitely notice the performance hit. IMO.
Cheers,
And here's sample code that changes out subforms in response to a tab_change...

 

[dfenton]

I don't see anything at all wrong with your design. It's just like dozens of apps I've implemented.

Whether or not you want to load subforms only on demand, or preload them when the form is loaded is up to you. I'd try it the easy way, i.e., permanently assigning them to the subform controls on the your 3rd and 4th tabs. It that's too slow, though, then you could use the tab control's OnChange event to load the subforms. I always use a blank subform as the default subform control for these so I can check the SourceObject and load the desired subform if it's only the blank subform.

I don't see any utility in trying to use a single subform control unless all the data you're working with in your form is in subforms and all the subforms have the same child/master link fields. Also, if you need to do anything with the data in the subform (like checking the RecordCount), you then have to have conditional code to check the SourceObject and then branch accordingly. I find it easier to just have a subform control for each subform and therefore it has a unique name and its own child/master link properties.

But don't optimize prematurely -- if the performance is fine, then there's no reason with the modest form you describe to be making it code-heavy. The default Access way is going to be easier and sounds to me like it ought to work just fine in your situation.

 

[ascaife]

Thanks for all your contributions everyone, and especially for the sample database, certainly lets me see things clearer and will no doubt come in handy.

Since I'm distributing a split database, I can leave the design for now then just change the front end later if required.

 

[missinglinq]

Just as an aside; GlaxiomAtHome is incorrect in saying:

"Having multiple controls bound to the same fields of the same table just isn't done. There would be a conflict between the values in the controls when the record was updated."

There are times when this is done. I have a hack, being used by myself and others, where this is done. There is no conflict because when data is edited in one textbox bound to a field and the control is exited, the BeforeUpdate and AfterUpdate event for the textbox fires, and the second textbox bound to the same field is updated as well!

Having said that, it is a unique situation that requires this.

I second the comments here about tabbed forms generally being a good design idea. It's not the number of tabbed pages, but rather, as has been pointed out, what you do with them and what you place on them.

 

[Simon_MT]

This maybe a case of "suck it and see", yes I do use Tab with subforms using the same table but not the same record. To me, the tabs are useful to summarise information and then allowing progession to a full or complete entry screens. I did find that showing the current and Archive stock did slow things down so I removed the Source Object from the SubForm on the History Tab and set this only when this tab is accessed.

Simon

 

[Galaxiom]

Just as an aside; GlaxiomAtHome is incorrect in saying:

"Having multiple controls bound to the same fields of the same table just isn't done. There would be a conflict between the values in the controls when the record was updated."

There are times when this is done. I have a hack, being used by myself and others, where this is done. There is no conflict because when data is edited in one textbox bound to a field and the control is exited, the BeforeUpdate and AfterUpdate event for the textbox fires, and the second textbox bound to the same field is updated as well!

Thanks for explaining that missinglinq.

So even though the value in the table is not updated until the form moves to a new record, the second control is updated automatically to the new value in the other control. I would not have guessed that.

It implies that the controls are actually displaying some intermediate store which is passed back to the table when the record is updated. I kind of assumed there was only the table value and the value in the control.

I learn something here every day.

 

[Simon_MT]

If the record is the same between the two tabs then you save the record and Requery the second Tab before you proceed to the next tab and whatever was updated would be saved.

Simon

 

[Galaxiom]

If the record is the same between the two tabs then you save the record and Requery the second Tab before you proceed to the next tab and whatever was updated would be saved.

If I have understood your post correctly what you say is not necessary. Tabs are just a layout tool. Controls on different tabs of the same form behave exactly as they would on an untabbed form.

When the value in the control on the first tab is changed and the focus moved away, the value also changes in other controls bound to the same field but located on another tab.

However the value in the table does not change until moving to another record.

 

[Simon_MT]

The record on the first tab maybe "Dirty" so I as a matter of course check and write the changes away before I do more changes. I get at times "The record has already been changed by another user ... ". This happens been calling a Dialog Box to make changes to the same record and the subsequent write back.

Simon

 

[dfenton]

The record on the first tab maybe "Dirty" so I as a matter of course check and write the changes away before I do more changes. I get at times "The record has already been changed by another user ... ". This happens been calling a Dialog Box to make changes to the same record and the subsequent write back.

This is only because you are editing the data in subforms. If you have the data on the MAIN FORM, there is no problem.

I really can't see having the same table on two different subforms if both are editable -- this makes no sense to me.

If there are more fields than fit on one page of your tab, then use a tab on the subform, so you have a tab within a tab.

While that isn't as flat a hierarchy, it would much more represent the data structure and would be much easier to implement.