Re: Creating Modeless Dialogs continually causing application to grow
Hey Joe,
The example code that I provided was just a quick modification to a modeless
example that I got off codeproject.
Anyway, here is what I've found out. Apparently the event loop requires
some downtime. I.E., time to do idle processing , etc. Having a tight set
of events that repeat seems to not allow the system to reclaim resources. To
solve the problem, I modified the logic as follows:
// This is the button press callback to actuate the test...
void CModelessDemoDlg::OnBnClickedButton1()
{
// Test to slam the app with lots of modeless dialogs
PostMessage(MODELESS_TEST, 0, 0);
}
// Message callback for the MODELESS_TEST message
LRESULT CModelessDemoDlg::OnModelessTest(WPARAM w, LPARAM l)
{
// Don't start the modeless dialog right away... do it via a
timer firing
// This allows the main to do idle processing and other
processing
SetTimer(THROTTLE_TIMER, 100, NULL);
return 0;
}
// Timer that will fire and start the modeless dialog...
void CModelessDemoDlg::OnTimer(UINT nIDEvent)
{
switch (nIDEvent)
{
case THROTTLE_TIMER:
{
KillTimer(THROTTLE_TIMER);
m_pmodeless = new CModeless(this);
m_pmodeless->Create(CModeless::IDD,this);
//m_pmodeless->ShowWindow(SW_SHOW);
}
break;
default:
break;
}
__super::OnTimer(nIDEvent);
}
Doing the above seems to help minimize application memory growth. Not
exactly sure why, but appears to have something to do with the dialog and the
modeless always doing something via messaging and the main app never getting
any time. This seems to have solved my problem.
Brief history as to what I'm doing:
I need to use modeless dialogs due to the nature of the application I am
writing. I have a main dialog that processes a user defined scripting
language. This language allows them to control external devices, get data
from a remote server, provide assorted modeless dialogs for user interaction,
etc. The problem that I was having is one of the script commands allows the
user to spawn another dialog to run another script as a subroutine. So, it
cannot be modal... the main dialog may have other dialogs that the user can
interact with while the subroutine is running. When the subroutine (modeless
dialog) finishes, it signals the main dialog that it may continue on in the
main script. Our users have made tight loops in the language that run a ton
of different subroutines. Over time the main application grows in memory due
to the frequency of running all these modeless dialogs. Adding the timer to
give the main application a moment of rest seems to remove the modelss dialog
memory growth. Complicated and hard to explain in a paragraph.
I'd welcome any comments should someone have more detailed knowledge of the
windows event driven system and provide more insight into the problem.
Thanks again,
Art
"Joseph M. Newcomer" wrote:
It may be due to storage fragmentation. But are you convinced you don't have a storage
leak somewhere? THis looks interesting, I'm going to explore it a bit.
What do you men "the main application waits for the modal dialog to finish"? This would
make it a modal dialog, which is not the same. And there is no "waiting" I see here.
Also, it is a really good idea to rename controls from the completely useless IDC_BUTTONn
values to something meaningful so you have some idea what is going on in your code, e.g.,
it should have been called IDC_CREATE_LOTS_OF_MODELESS_DIALOGS or something else that
communicates what it does.
See style comments below...
joe
On Fri, 4 May 2007 08:41:00 -0700, Art <Art@discussions.microsoft.com> wrote:
I have a dialog applicatin that needs to create modeless dialogs over and
over again. The main application waits for the modeless dialog to finish,
then repeats the procedure. I've written a simple test application that
seems to exhibit the same symptoms.
Main Dialog with some code removed to simplify: ( NOTE:
CModelessDemoDlg::OnBnClickedButton1() is used to begin the test of creating
modeless dialogs)
CModelessDemoDlg::CModelessDemoDlg(CWnd* pParent /*=NULL*/)
: CDialog(CModelessDemoDlg::IDD, pParent)
, m_pmodeless(NULL)
, m_text(_T(""))
{
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
}
void CModelessDemoDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Text(pDX, IDC_EDIT1, m_text);
}
BEGIN_MESSAGE_MAP(CModelessDemoDlg, CDialog)
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
//}}AFX_MSG_MAP
ON_BN_CLICKED(IDC_BUTTON1, OnBnClickedButton1)
ON_MESSAGE(MODELESS_TEST, OnModelessTest)
END_MESSAGE_MAP()
// CModelessDemoDlg message handlers
BOOL CModelessDemoDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// Set the icon for this dialog. The framework does this automatically
// when the application's main window is not a dialog
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
// TODO: Add extra initialization here
m_pmodeless = NULL;
return TRUE; // return TRUE unless you set the focus to a control
}
void CModelessDemoDlg::OnBnClickedButton1()
{
if(m_pmodeless)
m_pmodeless->SetForegroundWindow();
else
{
// Test to slam the app with lots of modeless dialogs that simply come / go
PostMessage(MODELESS_TEST, 0, 0);
}
}
LRESULT CModelessDemoDlg::OnModelessTest(WPARAM w, LPARAM l)
*****
If you don't use the parameters, get rid of the names.
...OnModelessTest(WPARAM, LPARAM)
would be sufficient
*****
{
m_pmodeless = new CModeless(this);
m_pmodeless->Create(CModeless::IDD,GetDesktopWindow());
*****
Why are you making the desktop be the parent? This is very risky. It means the app can
cover the dialogs.
*****
//m_pmodeless->ShowWindow(SW_SHOW);
return 0;
}
Modeless Dialog: ( Note: OnInitDialog posts a message that will cause the
dialog to be destroyed... prior to this another message is posted back to the
main dialog to cause another modeless dialog to eventually be created)
****
I don't see where "prior to this" the message is posted. Or is "this" referencing
"destroyed"? Did you mean to say "OnInitDialog posts a message that will cause the dialog
to be destroyed, and in the PostNcDestroy handler a message is posted which will cause
another modeless dialog to be created"?
****
IMPLEMENT_DYNAMIC(CModeless, CDialog)
CModeless::CModeless(CWnd* pParent /*=NULL*/)
: CDialog(CModeless::IDD, pParent)
, m_text(_T(""))
{
m_pParent = pParent;
****
I presume m_pParent is a CWnd *
****
}
CModeless::~CModeless()
{
}
void CModeless::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Text(pDX, IDC_EDIT1, m_text);
}
BEGIN_MESSAGE_MAP(CModeless, CDialog)
ON_BN_CLICKED(IDOK, OnBnClickedOk)
ON_BN_CLICKED(IDCANCEL, OnBnClickedCancel)
ON_MESSAGE(END_RUNNER, OnEndRunner)
END_MESSAGE_MAP()
BOOL CModeless::OnInitDialog()
{
CDialog::OnInitDialog();
PostMessage(END_RUNNER, 0, 0);
return TRUE; // return TRUE unless you set the focus to a control
}
// CModeless message handlers
void CModeless::PostNcDestroy()
{
CDialog::PostNcDestroy();
if(m_pParent)
{
((CModelessDemoDlg*)m_pParent)->m_pmodeless = NULL;
*****
This is an error. You should NEVER, EVER have the modelss dialog (or any dialog!) have
the SLIGHTEST CLUE about the class of its parent. Remove this line. Completely. It is
completely erroneous structure to have a dialog know anything about its parent; you can be
sure that if you #include the header file of the parent in a dialog, you have made a
fundamental design error. Why should the modeless dialog have a clue as to the name of a
variable in the parent?
*****
((CModelessDemoDlg*)m_pParent)->PostMessage(MODELESS_TEST, 0, 0);
*****
You do not need to cast this to the type of the parent to post a message. Remove the
cast. The default values for WPARAM and LPARAM are 0.
m_pParent->PostMessage(MODELESS_TEST);
would have been sufficient.
*****
}
delete this;
}
LRESULT CModeless::OnEndRunner(WPARAM w, LPARAM l)
****
Remove w and l as names, since you aren't using them
****
{
DestroyWindow();
return 0;
}
Any help / ideas as to how to solve this would be greatly appreciated.
Thanks in advance!
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm