>You say there are hundreds of fields. Have you considered an HTML page? This would require only ONE control on the form, a web browser. You could also front end the web brower control by instanting it at startup to get it into the application spaces menu.

This is a very intersting idea, but based on my understanding, it might be difficult to achieve other design goals. We've taken advantage of a lot of VFP gui functionality. We've done quite a bit of work with resize logic to make the form display at reasobable sizes in various screen formats. I am not sure how this would be possible in HTML.

Still. I'd like to look into it a bit, perhaps as a low-end alternative. Can you direct me to any further documentation on how to use HTML input forms with Foxpro? Are we talking about Active Server Pages? (

>
>Baring that a few more questions/areas you can check to speed up your form init:
>
>1. How deep are your control classes. Are you MANY levels down from the VFP base classes? The deeper your class hierarchy is, the more classes VFP has to load. So, if you have a very deep classes you could look at flatening them out and using hook classes for any specialized behavior.
>

They are three to five levels deep. I might give this a try. I moved the lowest two levels to a vcx. It actually took longer to instantiate based on these classes! Per the profiler, there doesn't seem to be much correspondence between the depth of the classes and the time to add the objects, but I will experiment a little more.

>2. Are you using access/asign events in your controls. I remember reading somewhere that classes that use them take 3 to 5 times longer to instantiate (which is what is happening to the control when you add object it to the form.)

good thought, but no. There are custom properties and methods on these classes however.

>3. Also, people have talked about delaying instantiation. Another thing you can do is delay binding. Non-bound controls should instantiate faster too. you can use the refresh to populate them with the value you want to display, and when the user tabs to a field you can bind it.

Delaying instantiation is not an option. I would rather load the delay onto the start up then when the user is waiting to display a page in a page frame.

Many of the controls are combo boxes whose lists are filled from an SQL select. However, the rowsource and rowsourcetype are not set until the field gets focus. I think this means we are already doing that.

>
>4. Finally, like some others have said, consider a small redisgn. Move some of the controls off of your form to child forms which come up when the user pushes a button. I would expect you can indentify a large percentage of the items on your form as less important or less often looked at.

Sure, but this would make our app look clunky. We already have an FP Win version of this that displays the entire form. Our users would percieve the change you are describing as a step backward.

The idea here is to show the user something which looks like a certain, standard government form. We've broken it up into three pages which is about as far as it can go.

This is a standard federal government real-estate transfer form. There are many programs for thsi application going back to the early days of pc's. Breaking the form up into smaller pieces is associated with older DOS programs ... What's the point of doing it in VFP if you Can't get a slick, modern-looking UI?

Bob, thank you very very much for your thoughful contributions.

Jack




>
>Good luck to ya...
>
>BOb