Help With Form Design With Many Fields 3

[Auguy]

I have an estimating project where I need approx 10 Tabs or 10 forms that each would contain approx 50 input items with about half of those being in grids. I have used tabbed forms with this many tabs but not with this many variables. Because the information varies greatly between the tabs I will need 10 different views to handle all of the data. I would like to use a tabbed form but a little worried about performance with this much data and 10 tabs. I was thinking about using 10 forms and position them so they appear to be tabs, but not sure if that would be any better. Looking for some advice on creating this form and or data handling.

Auguy
Sylvania/Toledo Ohio

 

[Mike Lewis]

Which version of VFP are you using? The reason I ask is that in earlier versions, if a form contained a page frame, all the controls on all the pages were instantiated as the form loads. With a large number of controls spread across multiple pages (as is the case here), there was a noticeable delay in loading the form.

The usual method of overcoming that was to programmatically add all the controls for each page when the page was first activated, via a call to AddObject in the Activate method. Doing that would make the loading of the form almost instantaneous, but introduce a much smaller delay when you first activate a given page.

However, I believe that in VFP 7.0 and later, that is no longer necessary. If I've got this right, VFP now delays the instantiation of the controls on the non-active pages until they are needed. (I have checked the Help, but can't find any documentation about this, so don't take my word for it.)

Similarly, in earlier versions, when you refreshed the form, all the controls on all the pages were refreshed, which again caused a delay. Now, only the controls on the active page are refreshed.

Regardless of the above, I would prefer to use a pageframe in the situation you describe. It easier than using multiple forms, both for the user and the developer. From a user interface point of view, the main problem is that ten or more tabs might look a bit crowded, and it might not be easy for all users to immediately find the tab they need. I often hide the built-in tabs (by setting the pageframe's Tabs property to .F.), and create a different control to let the user switch pages. A large graphical option group is usually a good choice for that.

So, on balance, I would say go with the pageframe. But that's very much a personal opinion.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Auguy]

Thanks Mike. VFP 9 SP2. I'll go with the pageframe. This is a re-write of an FPW program that was converted to VFP 6 a long time ago and badly needs updating. I was actually using 10 different forms on this in FPW using buttons to activate the proper form, so they are used to finding the page they need.

Auguy
Sylvania/Toledo Ohio

 

[JRB-Bldr]

I was actually using 10 different forms on this in FPW using buttons to activate the proper form, so they are used to finding the page they need.

If you already have an 'educated' user base who is already familiar with a method of operation, you might want to consider keeping things working in the same manner so that you can minimize the 'learning curve'. Especially if the previous approach was not too much different than the new approach (i.e. FPW GUI Screens to VFP Forms instead of FPD Text screens to VFP forms)

You have already mentioned another thing that to keep in mind - the form load speed.

Depending on how many queries, etc. are needed to be done to populate the form's various tab page grid sources, you might want to keep that in mind.
You will need to populate ALL of them with Something prior to the Form's appearing.

I did a complex client form (it started out simple, but 'evolved' to more and more complexity) which eventually had a good number of initial queries in the form Load method just to populate the various grids on the various tab pages.
Initially (when the form was simple) it was fine, but as things evolved, it took way too long.
The client had to wait a good while for the form to even display and it was un-acceptable.

So I changed the form to launch separate forms that were task specific (each with their own separate queries) thereby eliminating the need to run ALL queries during the primary form Load including those which populated grids were only occasionally utilized.
This noticeably improved the primary form launch time.

If you should stay with the single form approach make sure that you Disable Tab pages that are not associated with specific tasks so as to minimize the possibility of users wandering around into non-associated tab pages and 'messing' with the data.

Good Luck,
JRB-Bldr

 

[Auguy]

Thanks JRB, I think I will throw together a sample form and see what the speed is like and make a decision from there.

Auguy
Sylvania/Toledo Ohio

 

[Olaf Doschke]

In regard of query time you can start with empty cursors and requery them in page activates, eg use parameterized views and use them with no data on load, later set view parameters and requery. The same goes with sql queries or cursoradapters, just roll your own nodataonload with WHERE .F.

Besides that lazy load of data you can make use of member classes, we have page classes in VFP9, so instead of several forms you can design several pages.

One way to lazy load pageframes I used is two pageframes, one only showing it's tabs with empty pages, one starting with page1 only, which is extended in the moment a tab is activated. The secondary pageframe has no tabs shows (tabs=.f.) and only loads the pages the user activates.

All this is nice to play with, but several forms also are a nice solution, also in conjunction with form docking. In the end it would perhaps be best to use docked forms instead of a pageframe. It has the same interface, but users may undock single forms, the forms can have individual sizes, when undocked, etc. It's a quite flexible concept. But it also depends on interactivity between pages, if there is the need to let changes on page x influence page y, then it's perhaps easier on a single form, of course you can communicate to other pages by the DBFs, in short via shared data displayed by both pages, which is preferable anyway. Thinking in design patterns a complex form with interactive changes is best done by a mediator knowing what changes in what tablefield 1 should influence another tablefield 2 and where that will show up.

Bye, Olaf.

 

[Auguy]

Thanks Olaf, I usually use all of my views in the load with NoData and proceed as you have noted.

Auguy
Sylvania/Toledo Ohio

 

[NasibKalsi]

Happy New Year to All

I have 10 tabs on a form. Each tab loads its data only when clicked i.e. I open the tables(.dbf) only when the tab is clicked, and close when another tab is selected or on exit. I do not experience any slowness between tabed form and regular form. The only problem I experience is when making changes to the layout. It is a bit harder than a straight form. My vote is also for tabed form (Form with Pageframe).

nasib