Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Shaun E on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Memory Problem with a big Form 3

Status
Not open for further replies.

morcsea

Programmer
Feb 5, 2001
5
US
I designing a big form with a lot of information, I have a lot of control arrays becuase
I can't use more than 250 controls or 225, the problem is with the memory is
getting big and I don't know what is the best way to handle it.

If anybody can help me, I'll aprecite very much.

Thanks
 
You might consider breaking the form up into different forms if that's possible. Or you might try using a tab control. The other option would be to rethink the logic of how the information is presented to the user. Snaggs
tribesaddict@swbell.net
2 wire mesh butchering gloves:
1 5-finger, 1 3-finger, pair: $15
 
If you have one big table, you can use MSAccess to make queries in the MDB file based on only the fields you want to see at any one time and use the queries as recordsources for a number of smaller forms. You are not transferring so much data every time you change forms and more data is held on the disk instead of memory.
If using recordsets in code, set them to 'nothing' when you leave each form.
Also you probably should have used related sub tables and forms for items that are common to one particular area instead of putting everything on one table.
 
I can't believe you have a single form with over 250 fields on it. You really should be looking at which fields could be grouped onto subforms (use an sstab control), Or even better forms which are loaded on request.

With so many fields (I assume derived from a single table) can your problem may not be just with the form. Each record in your table must be fairly large too. Isn't there information which is repeated and could be stored in a separate table??.

Validating so many controls must be a nightmare too.

Normalise your tables (there should be as little repetition as possible).
Regards
Kirk.
 
While VB's limit is 250 controls, I've found that going over 150 on a form causes slow load times and sometimes "flaky" behavior.

Try and break it up onto different forms. If you have related fields (like telephone numbers with different edit boxes for area code, exchange and number), you might try creating a custom OCX to combine them. This should present one control to VB, instead of the three or more before.

Chip H.


 
I have to agree with everyone else here by saying that anything over 200 controls on a single form is way too many. And I am used to large applications. I currently work for a company that developed a VB app with over 180 forms, but each form only had a handful on controls. Putting that many contols on one form will overwhelm your user. But, if you have to put that much information on one screen, have you considered using a single grid control? I've used Sheridan Grids before and you can combine radio buttons, text boxes, command buttons, and drop down combo boxes onto a single Grid OCX. ITs just a thought . . . I would still suggest breaking up your information into multiple forms, but if you can't do that, then take a look at some of the grid controls.
 
I agree with JMarler of what he suggests. It is proven that the grid control is much faster for the simple reason that it is just a single control unlike the many text boxes that you might have used. If you have related data then it will be a good idea to see if you can implement your form in a scrollable grid. I am sure it will work great.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top