| Author |
Topic |
|
|
mmp
31 Posts |
 Posted - 05 May 2003 : 16:37:56
|
Hi All,
I am having a serious problem with a Win CE MFC application. To explain very briefly, I created a new project (MFC) and I added a button to the main dialog. After that, I created another dialog (and a class for it) where I added (with the design view) something like 106 buttons. Then, I added a handler function for the button on my main dialog so that it displays the dialog with the 106 buttons (as modal.) Here is what really goes on:
in the mainDlg.cpp file:
void mainDlg::OnButton1()
{
ButtonsDialog TheButtonsDialog;
TheButtonsDialog.DoModal();
}
So, I run the application, I see the main dialog, I press the button1 and I get the other dialog full of buttons. Then, I dismiss it by pressing ok and I return to the main dialog. I press the button again and I see the buttons dialog again. Repeating this process for around 65-70 times, it eventually locked up! This should not really happen, should it ?
Looking at the code, it is clear that the dialog with the buttons is declared ON THE STACK so when it goes out of scope, it should destroy its child windows (in this case, the buttons) and then destroy itself. Interestingly enough, this does not seem to happen since it will eventually lock up as if memory was leaked. Indeed, dissasembling the code I see the problem arising at instructions such as cmp dword ptr [ecx*4-7], edx [compare with a pointer location, thus memory operation]. In fact, it is always clear that the problems arise when an ASM instruction involving a pointer [ptr] happens. So, it has to deal with the memory but why ? Why would memory be leaked ? Again, the buttons were "created" by just adding them to the dialog in the design view. I did not even map them to any variables or anything, I just simply added them (dragged them on the dialog.) When I saw that I had this problem, I also then added variables to represent the buttons, thinking that in this way maybe they will actually call the destructor of the CButton class but the exact thing happened: it locked up. I then proceeded to derive a class from the CButton so that I can override the destructor and add a AfxMessageBox((CString)"destroyed.."); to see if it is actually called; and it was called.
If I added fewer buttons to the dialog, such as 18 instead of 106 it just took longer until it eventually locked up (needed to display the dialog around 400 times for this to happen..)
I know that Windows CE has a garbage collection mechanism that gets triggerd on OnIdle, but I thought that the garbage collection dealt more with the heap while objects declared on the stack should automatically be destroyed when they go out of scope (of course, with the exception of the underlaying handles such as HPEN, HBRUSH, etc that require an explicit DeleteObject.)
I tried the exact same thing with the Visual C++ 6.0 (desktop version) and I did not have this problem (of course, it has a lot more memory available to it, but analyzing it with a memory watch tool it looked like it did not even feel it.)
I also tried allocating the dialog on the heap then deleting it when I was done with it, but I had the exact same result. Other things that I tried involved mapping the buttons to variables of type CButton (using class wizard), moving them to the .cpp file and declaring them as STATIC... nothing worked.
Anyone have any idea what is going on?
Marius
|
|
|
mmp
31 Posts |
Posted - 06 May 2003 : 10:36:04
|
Follow up: It seems as though the problem only occurs in the simulation (H/PC Pro 2.11) -- on the actual evaluation system that I have from ADS (GC+) it does not happen. The only difference is that on the emulator I am running a DEBUG version for x86 while on the evaluation system I am running a RELEASE version for Strong ARM. Usually, in DEBUG mode things are a lot more picky (a lot more checks are made to ensure proper operation) thus I am not sure if it is an emulation problem or a problem w/ the MFC for Win CE.
Marius
|
 |
|
|
ctacke
877 Posts |
Posted - 06 May 2003 : 10:58:24
|
| It also may be an issue in MFC that existed in CE 2.11 and was fixed in 3.0. |
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
Win CE + MFC, destructors, memory.
Forum Locked
Send Topic to a Friend
Printer Friendly