>I've seen comments in various articles and other places that too many controls on forms and in containers can significantly affect the performance of an application. Through evolution, our application has as many as 500 objects (not counting columns, and headers, etc.). There are a few activex controls as well and we are beginning to see some flakeyness. Besides the obvious that we need to re-engineer the base of this application,...
>
>Has anybody ever done any research to determine a reasonable threshhold for the number of controls in a form?
>
>Thanks.
>
>- Tom Mc -
>Media Systems, Inc.

IMO, there is no clear cut answer for this. Good beginning, isn't it; just what you wanted to hear. :-) It's relative. The number of controls don't have as much effect as what each control does as it instantiates. You can have 1000 controls on a form running on a fast machine and all they do is display and the performance hit will be relatively small. But if you have 10 controls that each have to perform a SQL Select for their controlsource, then you may have a problem.

During the instantiation process of a form, all the form's controls are initialized first and then the form itself. Because of this, the Show method of the form (this displays the form) is delayed substantially by having a large number of controls on the form that each take require more than minimal instantiation time. Large numbers of controls on a single level also play a part in performance hits when you try to get an object reference to a control (this is just conjecture).

There are several workarounds. You could break your single form into multiple forms. This is by the easiest (IMO) and the only thing to you really have to remember is that the "child" forms must have the Datasession property set to default so they participate in the "parent" form's datasession.

You could also break your single form up using a pageframe and "delayed instantiation". This means you create all your pages on your form with all of their controls. Then select all the controls on a single page and save that as a class. During the initial instantiation of the form, only display the controls on the first page of the pageframe. If they try to go to another page, check for the existence of the container that holds the controls for that page and if it doesn't exist, AddObject the container to the page. You will have to change the position of the container (it always instantiates low and to the right) and make it visible. This way the end user doesn't feel the performance hit for those controls unless they go to that page. This also breaks up the levels or layers of objects.

One last thing to mention. Look into using the Coverage Profiler. Thi swill tell you how long it takes for your controls and form to instantiate. You can pin point bottlenecks and perhaps find a way to reduce the time of instantiation.