Loading a Large Executable

Question:
We are experiencing real speed problems with this platformon Windows 95. we are using Pentium 100 machineswith 16megs of ram. The project compiles to about 3megs. The main screens are each about 200 -300kThis is not a MDI app so each form has a toolbar and menu. There are about 25 of these forms.we use Doevents and minimize the code in the formload / activate eventsWe use a lot of third party OCX’s and initially loading the app and the DLL’s takes about30-40 sec’s. Subsequent forms take about 10 sec’s.We MUST get this time down. Is there anything you can suggest?

Answer:
t sounds like you’ve documented your entire problem in your question:

  1. Lots of graphical controls (toolbars) that take time and memory to load.
  2. 25 Forms — not a lot, but the graphics on each add to the executable size
  3. The minimal event code won’t help your overall problem, unfortunately
  4. Lots of OCXs and DLLs.
Unfortunately, the only solutions I can offer would require major redesign work, as I’m sure you’ve already seen.
  1. Use a common toolbar. They’re a little bit of work to coordinate, but they make for a much easier program to manage, as well as a better user interface. Same thing with the menus…with a bit of work you can use a common set of menus that trigger code in the MDI child forms. But this might not work in your case…I don’t know your application.
  2. Reuse forms as much as possible. With VB4 and the advent of classes, a data entry form could be used for both adding and editing records, simply by adding an additional public method to the form. If this sounds promising, I can elaborate.
  3. No solution needed.
  4. Are all the OCXs you’re using really necessary? Have you removed any libraries or controls from your project that you aren’t using? Can any of the tasks done by OCXs be done by direct API calls? These are some of the things I would look at.

Share the Post:
Share on facebook
Share on twitter
Share on linkedin

Overview

Recent Articles: