Bret,

Thanks for the info. That's alot to think about, but I think I am going to try it along the lines you are describing here. Can you tell me were I can get that Jim Booth article to read. I am unable to click on the "auto-link" you sent me as I am not a full UT member....yet.

Thanks

Elgin


>I have the same solution here for a configuration management form I have created. The form allows the user to query configuration management data from only one form. When I started I had to determine when and where to get my data. The form has a page frame with 37 tabs and each tab has a page frame with 4-6 tabs on it. I noticed that when the form was being developed that it was slow in coming up because of all the overhead of the data views to open and the tabs to create on the form. Mostly I opened any and all data I would need in the Load event, but I had to rethink that as it is not logical to open a view on page tab 24 unless the user went to their. So I just open the database in the load event and then in the activate code of the page I checked to see if the view was already present if it was not I opened the view. This cut down on overhead quite a bit, but my form still came up extremely slow due to all the pages being instantiated. So with the universal threads help and
>Jim Booth's article on delaying instantiation of pages until needed. I modified my form creating a class for every page that did not need to come up unless the user asked for it. The page classes were saved and with the help of a proxy class on each page, that builds the page on the fly from the class saved previously. I was able to speed the form up dramtically.
>
>I have also used the technique of calling the view inside the requery method of a list that would show the data. Thus if the user looked at main data but never asked for child data, then the requery method of a list is not called and that reduced overhead.
>
>Hope this helps.