Hi Jim and Sze Sze,

Actually, the issue is more complicated than that. instantiating certain objects are not registered by the coverage profiler.

For example you can't register how much time it takes to load the dataenvironment this way. To work arround this use:

1. Set the autoopentables property to .f.
2. In the load event THISFORM.dataenvironment.opentables

In this case, the coverage profiler will give you a hint how much time it takes.

Watch out when using views. They can take a lot of time to load. It might be better to set NoDataOnLoad to .t. and requery the view at some time when the form is visible.

Another issue is the time needed to instantiate the native controls and the time needed to bind them to the datasources. Comboboxes and listboxes are notorious because when they're bound to many items it takes quite a while to instantiate. When you are using textboxes based on a custom class, you classcode might be the bottleneck. Try to minimize the custom code in the INIT event of such objects.

It might be wise to use a late binding strategy. Controls on another page only need to be bound or loaded when this page is activated.

To have a clue where the performance bottleneck is, you might to remove a few controls at a time and test performance, remove some more controls etc.

Last but not least, Don't use INDEXes ON deleted() when not absulutely neccesary. When having large tables (more than a few thousand records) it takes a lot more time to just open them when SET DELETE = OFF.

Walter,

>You can stop guessing and use the coverage/profiler utility in VFP to find out exactly where the time is being spent during yuour form's instantiation.
>
>Open the debugger and choose the coverage logging. Set the output to go to a file of your choice. Now run your form. Now quit your form. Now choose Coverage/Profiler from the Tools menu.
>
>When the coverage/profiler asks you for a file to open point it to the one you had the coverage logging create for you. Once the coverage profiler is open switch it to the profiling mode and you will see that all of the code executed is listed with the number of times each line ran and the time it took to run each line.
>
>Remember that every object that exists must be created during the creation of the form. Each object will run its Init event so any code you have in any Init's is running during form creation. Also the fomr itself runs its Load, Init, activate, and refresh as well as its Gotfocus. The Gotfocus of the first object in the fomr's tab order also runs. If you have any filters set for the tables that drive your grids, these filters must be set up as well, keep in mind that grids and filters don't behave very well with each other in terms of performance..