We are currently assisting on a project where the main window is an MDI Frame that automatically loads 7 MDI Child windows during the CREATE event. However, by the time the entire window is up and running, system resources have dropped over %50 (typically going from %77 to %23) and not much else can be done (including closing OpenInsight.)

Are there any tips for optimizing this process?

Thanks,

[email protected]

SRP Computer Solutions

Hi Don,

If you *have* to launch all these windows at once there's not much you can do as it's probably the User stack being hammered by all the controls. I've run into this problem before when using MDI frames to simulate tabs, but the only way I really got around this was to destroy the child windows when they became inactive and save their data off somewhere, re-creating and re-loading as necessary.

A couple of things you could also try…

1) Replacing ComboBoxes with and edit line and button to lauch a popup (that way you don't have an extra listbox component hanging around )

2) Replace buttons with bitmaps and control them yourself (Not very attractive!)

3) Try distributing the controls across less windows if possible.

4) A total design re-think?

[email protected]

Sprezzatura Ltd

World Leaders in all things RevSoft

Hi Carl,

I've run into this problem before when using MDI frames to simulate tabs

This is exactly what is being done - a seven tab window using MDI due to control limitations on a single form. I will take your ideas under advisement. Here's a few more specific questions related to this issue:

1. I believe a fair amount of code get's called as well during the CREATE event (several called subroutines). Can this effect resources? Are there ways of minimizing the impact?

2. Regarding the idea of destroying the child windows - can you give me more specifics on this? Will this approach be quicker than writing, closing, opening, and reading each time? As you can guess, we want to appearance of switching from one tab to another to be relatively smooth and quick.

Thanks for you help,

[email protected]

SRP Computer Solutions

Hi Don,

]]. I believe a fair amount of code get's called as well during the CREATE event (several called subroutines). Can this effect resources? Are there ways of minimizing the impact?].Regarding the idea of destroying the child windows - can you give me more specifics on this?Sprezzatura Ltd[/url]

World Leaders in all things RevSoft

Hi Carl,

Thanks for the elaboration. I'll see what I can do along those lines.

You could alos disable the REDRAW of the MDICLIENT control while you do all this. This may make the change appear faster…

I thought REDRAW was strictly a window property. Can it be applied to specific controls, or at least the MDICLIENT portion of the frame?

Thanks,

[email protected]

SRP Computer Solutions

I see that it does apply to "All controls". I mistook the name of the parameter, windowID, to mean OI windows. But I guess it is using it in a true Window's sense of the term.

Thanks again,

[email protected]

SRP Computer Solutions

Don,

We have the same problems with our app. It's totally a function of the number of controls you have active.

We were able to postpone dealing with the problem by running this tiny utility that manages windows resources dynamically. It's called RamDoubler (I know, boo hiss hiss, a memory manager, but what can I say — this one works unabtrusively and flawlessly, and has allowed us to field our products for more than years).

The problem is, Ramdoubler only works for Win3x. Worse, we've found that Win95 still doesn't manage its windows handles and gdi resources nearly was well as Win3x running RamDoubler.

So, we're in the same boat — since we want to port our application to win95/98 this year, it looks there is no way around at least some code changes.

If we happen upon an easy solution, we'll post it here.

Good luck,

Andy

View this thread on the forum...