15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


GetDlgItem and Assertion Failed.

Marco Altese -- marko@mbox.vol.it
Monday, November 25, 1996

Environment: VC++ 1.52, Windows 95

I have created a Dialog that opens a second Dialog through a button. In the
second Dialog there are 96 Cedit controls and I have initialized them in the
OnInitDialog function. I have defined, into OnInitDialog, a pointer variable,
CEdit* pEd, and I use this variable for all the CEdit controls in the following
way:

        pEd = (CEdit*) GetDlgItem(IDC_EDIT1);
	pEd->SetWindowText("  1");        
	pEd = (CEdit*) GetDlgItem(IDC_EDIT2);
	pEd->SetWindowText("  2");        
	pEd = (CEdit*) GetDlgItem(IDC_EDIT3);
	pEd->SetWindowText("  3.");       
        ....................................
        ....................................

Now, if I open the second Dialog and then close it with the Cancel button for
many times in sequence (Open and Close, Open and Close, .....) the application
reports an assertion failed in file dlgcore.cpp line 69. Which is the problem?
If I remove all the lines above the problem disappear. GetDlgItem "eats" any 
resource?

Thanks.

     Marco Altese




David Lowndes -- David.Lowndes@bj.co.uk
Wednesday, November 27, 1996

[Mini-digest: 5 responses]

> I have created a Dialog that opens a second Dialog through a button. 
In the
second Dialog there are 96 Cedit controls and I have initialized them 
in the
OnInitDialog function. I have defined, into OnInitDialog, a pointer 
variable,
CEdit* pEd, and I use this variable for all the CEdit controls in the 
following
way:

<

Marco,

You're probably running out of memory because CWnd::GetDlgItem creates 
temporary CWnd's that are normally deleted in the default MFC idle 
processing. In your situation under 16 bit MFC you're not getting back 
to the idle loop, so these resources aren't being freed off.

The solution is to use the SetDlgItemText routine which doesn't create 
any intermediate CWnds:

pEd = (CEdit*) GetDlgItem(IDC_EDIT1);
	pEd->SetWindowText("  1");

is equivalent to:

	SetDlgItemText( IDC_EDIT1, "  1" );

Dave Lowndes

-----From: Mario Contestabile

>I have created a Dialog that opens a second Dialog through a button. In the
>second Dialog there are 96 Cedit controls and I have initialized them in the
>OnInitDialog function. I have defined, into OnInitDialog, a pointer variable,
>CEdit* pEd, and I use this variable for all the CEdit controls in the following
>way:
>
>        pEd = (CEdit*) GetDlgItem(IDC_EDIT1);
> pEd->SetWindowText("  1");        
> pEd = (CEdit*) GetDlgItem(IDC_EDIT2);

Perhaps you should try SetDlgItemText(IDC_EDIT1, "  1");
to avoid the casting and reduce the number of function calls by half.

mcontest@universal.com

-----From: "Umesh Chandwani" 

I think the problem is this.
MFC deletes temporary CWnd objects during OnIdle processing.
You are using modal dialog boxes which i think block this processing.
The temporary objects created using GetDlgItem do not get deleted 
& the system runs out of memory causing the assertion. I do not have VC 1.52 to
check the nature of the assertion.

Suggestion:-> Use permanent windows objects using DDX_CONTROL


-----From: Michael Patterson 

Can you use a loop?  Such as:

      for (int iT = 0; iT < 96; iT++)
      {
           CEdit* pEdit = (CEdit*)GetDlgItem(IDC_EDIT1 + iT);
           ::wsprintf(szTemp, "  %d", iT); // sample text
           pEdit->SetWindowText((LPCSTR)szTemp);
      }

Here's the text that goes along w/ your error message:
"Warning: something went wrong in dialog init\n"

Mike


-----From: =?iso-8859-1?Q?Klaus_G=FCtter?= 

The Assertion in dlgcore.cpp, line 69, is hit when there is an exception
during dialog initialization (WM_SETFONT and WM_INITDIALOG). 
f you run your app under the debugger, you should see a trace in the
output window telling you the type of exception (e.g. CMemoryException).
If you know this type, put a breakpoint in the corresponding
AfxThrow...Exception function (e.g. AfxThrowMemoryException) function.
When the debugger stops, look at the call stack to determine tha exact
location and cause of the failure.

- Klaus





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