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
| Вернуться в корень Архива
|