Исходники.RU - Информационный сервер для программистов: исходники со всего света.

Out of System & User Resources


MIKEMIKE@msn.com
Tuesday, January 09, 1996

Hi

I have a CMDIChildFrame that contains approx 100 window handles in its View.

After opening just 3 CMDIChildFrame, CRASH!  Yup, CRASH!

Win95 crashes because I am out of System & User Resource memory.  

I "assume" this is because of the 100 window handles added from each frame.

Any suggestions?  

/V\ I |< E /V\ I |< E @ M S N . C O M


Mike Blaszczak -- mikeblas@interserv.com
Wednesday, January 10, 1996

On Tue, 9 Jan 96, "MIKEMIKE "  wrote:
>Hi
>I have a CMDIChildFrame that contains approx 100 window handles in its View.
>After opening just 3 CMDIChildFrame, CRASH!  Yup, CRASH!
>Win95 crashes because I am out of System & User Resource memory.  
>I "assume" this is because of the 100 window handles added from each frame.
>Any suggestions?  

Is this a 16-bit app, or a 32-bit app?

.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");

MIKEMIKE@msn.com
Friday, January 12, 1996

Hi Mike

Platform and etc: Visual C++ 4.0 Intel, MFC 4.0, Win95, on a Pentium 120, 
32meg 

To reiterate, this MDI child frame has several views (Csplitter) and about 100 
 WS_CHILD windows in all

Each newly opened MDI child frame chews up about 25% of the system and user 
resources.

MIKEMIKE@MSN.COM

P.S. Sorry Mike...I broke your first suggestion of the list
1) Make sure you name which version, exactly, of MFC you're using.  You should 

explain, too, if you're using Visual C++, Symantec, or Watcom, and you should 
say which version of the tools you're using.

----------
From:  owner-mfc-l@netcom.com on behalf of mikeblas@interserv.com
Sent:  Wednesday, January 10, 1996 4:21 PM
To:  mfc-l@netcom.com
Subject:  Re: Out of System & User Resources

On Tue, 9 Jan 96, "MIKEMIKE "  wrote:
>Hi
>I have a CMDIChildFrame that contains approx 100 window handles in its View.
>After opening just 3 CMDIChildFrame, CRASH!  Yup, CRASH!
>Win95 crashes because I am out of System & User Resource memory.  
>I "assume" this is because of the 100 window handles added from each frame.
>Any suggestions?  

Is this a 16-bit app, or a 32-bit app?

.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");

MIKEMIKE@msn.com
Saturday, January 13, 1996

[Mini-digest: 2 responses.]

Hi Mike

Ignorant and Naive question (everyone says No to this question):
Is there a way to have a "virtual System and User Memory segment in Win95"?  
Like how windows makes swaps RAM in and out

Responses to your email:

In ref to your comment
>> "You should split the Windows into chunks with different groups of 
>>child controls in there".  
Very curious, what do you exactly mean by this?

In ref to 
>>"Wow!  100 child windows?  What for?"...
It's a Sales Order/Inventory look up ChildFrame.  You know, Bill to Ship to 
Addresses, ship date, fob, ship via, etc etc Plus the inventory search window 
is 5 Sheets with 2 Pages each,  The detail is a Grid control I wrote that does 
use the flying dynamically created Cedits you are talking about.

In ref to 
>> you'll need to investigate some (hairy) technique where you draw some of 
the controls 
>> yourself 
I've been trying to avoid this, but I don't think it's going to happen.  There 
are certainly some nice benefits to CFormVIew layout.  You can lay it out in 
the resource editor nicely.  The only way I can think of to continue this is 
to load the CFormView, get the coordinates and then dumping the CFormView.

I am going to try and dissect the PerfMon code to see if I get use some of it 
to TRACE the decreasing System and User resources. Too bad there isn't some 
API for User & System Resources.  Maybe Jefrey Richter's book has it

In ref to 
>>"Jefrey Richter's book "Advanced Windows" has a chart in it that explains 
how 
>>much of each resource you can expect to have.  There's a similar chart in 
the 
>> Win32 SDK, if I remember correctly.  For Windows 95, the limits are lower 
>>than they are for WinNT.  For most resources, WinNT is unlimited.  For most 
>>resources, Win95 tops out when the data used to manage that resource hits 
>>some limit... you're hitting that limit."

Too bad NT doesn't mean Now Technology and not Next Technology.  I will 
certain read these resources after sending this email.

Thanks

----------
From:  mikeblas@interserv.com
Sent:  Friday, January 12, 1996 1:53 PM
To:  MIKEMIKE  
Subject:  RE: Out of System & User Resources

On Fri, 12 Jan 96, "MIKEMIKE "  wrote:
>Hi Mike
>
>Platform and etc: Visual C++ 4.0 Intel, MFC 4.0, Win95, on a Pentium 120, 
>32meg 
>
>To reiterate, this MDI child frame has several views (Csplitter)
>and about 100 
> WS_CHILD windows in all

Wow!  100 child windows?  What for?

>Each newly opened MDI child frame chews up about 25% of the system and user 
>resources.

No kidding!  The reason is obvious: those child windows need some memory, and 
they're getting it from one of the system heaps.  Since you have so many 
windows, you're using a lot of system heap.

>P.S. Sorry Mike...I broke your first suggestion of the list
>1) Make sure you name which version, exactly, of MFC you're using. 
>You should 

It's just that you would have saved two or three days in getting an answer.

Jefrey Richter's book "Advanced Windows" has a chart in it that explains how 
much of each resource you can expect to have.  There's a similar chart in the 
 Win32 SDK, if I remember correctly.  For Windows 95, the limits are lower 
than they are for WinNT.  For most resources, WinNT is unlimited.  For most 
resources, Win95 tops out when the data used to manage that resource hits 
some limit... you're hitting that limit.

There's really nothing you can do.  You have a very aggressive user 
interface; I'm not sure if you really need that many windows, but I'd tend to 
doubt it. You should split the Windows into chunks with different groups of 
child controls in there. If you really, really can't do that, you'll need to 
investigate some (hairy) technique where you draw some of the controls 
yourself. You could, for example, paint all of the controls and wait for the 
user to click or tab to another control.  Then, create that control 
dynamically since it's actually active.  When the user moves again, create 
that control and destroy the previous one.  Depending on what kind of 
controls these are, and how many kinds of each control you have in a group, 
you might want to keep the control window created and just move it from place 
to place.

This is obviously easy if all of your controls are edits--just bap an edit 
control around on your window in response to the user.  On the other hand, if 
you have controls with heavy interactions (like a group of radio buttons) you 
might have a hard time simulating what Windows is doing. So, for those cases, 
maybe you should just use the real Windows controls and then you'll get the 
most return for your extra effort.

You might want to start by painting your own static controls--they dont' do 
much work with the keyboard, and they are easy to paint.  They'll only save 
you a little bit of heap space, though...

.B ekiM
--
TCHAR szDisc[] = _T("These words are my own, but at least none of them are 
Japanese.");

-----From: "MIKEMIKE " 

Believe it or not it's 32 bit on Win95, MSVC 4.0, MFC 4.0

Every time I open a CMDIChildFrame, the System & User resources drop approx 
25%.  After 3 hit's, I get all sorts of create failures.

If it makes any difference the exact line of code I use to open the 
CMdiChildFrame in this MDI app 

(Called from CMainFrame object)
((CSearchApp*)AfxGetApp())->m_multiDocTemplate[5]->OpenDocumentFile(NULL);

Thanks for any assistance

/V\ I |< E /V\ I |< E @ M S N . C O M

Elliott Kleinrock -- ELLIOTT@flexi.com
Tuesday, January 16, 1996

The problem is not so much each screen as the fact that for each
DocTemplate there is a menu loaded. What you have to do is not
load a menu for each DocTemplate. This requires copying MFC
code and removing the part that loads the menu, and then calling
your new (menuless) loading function.

I know this sounds strange, but if you start your app with no screens
(or only 1) and then check your resources you will see that most of
them are taken before each screen is displayed.

If you want to display all 100 screens simoutanously then you are
probably going to have to do some very strange things.

The other thing that I do is to delay creating the DocTemplate until
just before I need it the first time, this speeds up the initial loading
of the application (not too important) and slows the loading of each
screen the first time slightly. But most importantly, it lowers the amout
of resources used if the user does not load every screen. If there are
screens that are always (or almost always) shown their
DocTemplates can be preloaded.

Here is the code to create a DocTemplate and show its view:

CDocument * FWinApp::CreateView(CMultiDocTemplate ** ptr, CRuntimeClass * 
DocClass,
                    CRuntimeClass * FrameClass, CRuntimeClass * ViewClass)
{
     FHourglass fhg(m_pMainWnd);

     CheckResources();
     if (ptr == NULL || *ptr == NULL)
     {
          *ptr = new CMultiDocTemplate(IDR_FLX7BAR, DocClass,
                                                            FrameClass, 
ViewClass);
          AddDocTemplate(*ptr);
     }

     CDocument * pDoc;
     pDoc = (*ptr)->OpenDocumentFile(NULL);  // note that this is on a 
CMultiDocTemplate and not the CWinApp
     return pDoc;
}

I'm not sure I have everything here, it was over a year ago that I did this
and I have forgotten many details.

Good Luck
     - Elliott
 ----------
From: owner-mfc-l
To: mfc-l; mikeblas
Subject: RE: Out of System & User Resources
Date: Saturday, January 13, 1996 2:15AM

[Mini-digest: 2 responses.]

Hi Mike

Ignorant and Naive question (everyone says No to this question):
Is there a way to have a "virtual System and User Memory segment in Win95"? 

Like how windows makes swaps RAM in and out

Responses to your email:

In ref to your comment
>> "You should split the Windows into chunks with different groups of
>>child controls in there".
Very curious, what do you exactly mean by this?

In ref to
>>"Wow!  100 child windows?  What for?"...
It's a Sales Order/Inventory look up ChildFrame.  You know, Bill to Ship to
Addresses, ship date, fob, ship via, etc etc Plus the inventory search 
window
is 5 Sheets with 2 Pages each,  The detail is a Grid control I wrote that
does
use the flying dynamically created Cedits you are talking about.

In ref to
>> you'll need to investigate some (hairy) technique where you draw some of
the controls
>> yourself
I've been trying to avoid this, but I don't think it's going to happen.
There
are certainly some nice benefits to CFormVIew layout.  You can lay it out in 

the resource editor nicely.  The only way I can think of to continue this is 

to load the CFormView, get the coordinates and then dumping the CFormView.

I am going to try and dissect the PerfMon code to see if I get use some of 
it
to TRACE the decreasing System and User resources. Too bad there isn't some
API for User & System Resources.  Maybe Jefrey Richter's book has it

In ref to
>>"Jefrey Richter's book "Advanced Windows" has a chart in it that explains
how
>>much of each resource you can expect to have.  There's a similar chart in
the
>> Win32 SDK, if I remember correctly.  For Windows 95, the limits are lower 

>>than they are for WinNT.  For most resources, WinNT is unlimited.  For 
most
>>resources, Win95 tops out when the data used to manage that resource hits
>>some limit... you're hitting that limit."

Too bad NT doesn't mean Now Technology and not Next Technology.  I will
certain read these resources after sending this email.

Thanks

 ----------
From:  mikeblas@interserv.com
Sent:  Friday, January 12, 1996 1:53 PM
To:  MIKEMIKE
Subject:  RE: Out of System & User Resources

On Fri, 12 Jan 96, "MIKEMIKE "  wrote:
>Hi Mike
>
>Platform and etc: Visual C++ 4.0 Intel, MFC 4.0, Win95, on a Pentium 120,
>32meg
>
>To reiterate, this MDI child frame has several views (Csplitter)
>and about 100
> WS_CHILD windows in all

Wow!  100 child windows?  What for?

>Each newly opened MDI child frame chews up about 25% of the system and user 

>resources.

No kidding!  The reason is obvious: those child windows need some memory, 
and
they're getting it from one of the system heaps.  Since you have so many
windows, you're using a lot of system heap.

>P.S. Sorry Mike...I broke your first suggestion of the list
>1) Make sure you name which version, exactly, of MFC you're using.
>You should

It's just that you would have saved two or three days in getting an answer.

Jefrey Richter's book "Advanced Windows" has a chart in it that explains how 

much of each resource you can expect to have.  There's a similar chart in 
the
 Win32 SDK, if I remember correctly.  For Windows 95, the limits are lower
than they are for WinNT.  For most resources, WinNT is unlimited.  For most
resources, Win95 tops out when the data used to manage that resource hits
some limit... you're hitting that limit.

There's really nothing you can do.  You have a very aggressive user
interface; I'm not sure if you really need that many windows, but I'd tend 
to
doubt it. You should split the Windows into chunks with different groups of
child controls in there. If you really, really can't do that, you'll need to 

investigate some (hairy) technique where you draw some of the controls
yourself. You could, for example, paint all of the controls and wait for the 

user to click or tab to another control.  Then, create that control
dynamically since it's actually active.  When the user moves again, create
that control and destroy the previous one.  Depending on what kind of
controls these are, and how many kinds of each control you have in a group,
you might want to keep the control window created and just move it from 
place
to place.

This is obviously easy if all of your controls are edits--just bap an edit
control around on your window in response to the user.  On the other hand, 
if
you have controls with heavy interactions (like a group of radio buttons) 
you
might have a hard time simulating what Windows is doing. So, for those 
cases,
maybe you should just use the real Windows controls and then you'll get the
most return for your extra effort.

You might want to start by painting your own static controls--they dont' do
much work with the keyboard, and they are easy to paint.  They'll only save
you a little bit of heap space, though...

.B ekiM
 --
TCHAR szDisc[] = _T("These words are my own, but at least none of them are
Japanese.");

 -----From: "MIKEMIKE " 

Believe it or not it's 32 bit on Win95, MSVC 4.0, MFC 4.0

Every time I open a CMDIChildFrame, the System & User resources drop approx
25%.  After 3 hit's, I get all sorts of create failures.

If it makes any difference the exact line of code I use to open the
CMdiChildFrame in this MDI app

(Called from CMainFrame object)
((CSearchApp*)AfxGetApp())->m_multiDocTemplate[5]->OpenDocumentFile(NULL);

Thanks for any assistance

/V\ I |< E /V\ I |< E @ M S N . C O M

| Вернуться в корень Архива |