Assertion failure in CWnd::DestroyWindow

[txjump]

Hi,

Ive created a library w/ a dialog, linked it to a dll, and am testing the dll w/ an exe. the problem occurs when i create an instance of the library class in the dll class or as a global in the dll. the exe calls the dll which in turns calls the lib. the lib class does its thing successfully but when it closes the lib class dialog, i get an assertion failure in DestroyWindow at the line

ASSERT(m_hWnd == hWndOrig);

in the function BOOL CWnd:estroyWindow() of wincore.cpp

what do i need to set the m_hWnd to so that i dont get the assertion error? and does this get set before the dialog DoModal is called?

i dont get this error any other time, just when the DoModal is being called inside the dll. ive tested the dialog from an exe and it works fine.

any suggestions?
thanks,
txjump

 

[qednick]

Hard to say without seeing your project files. Are you creating the dialog on the stack or the heap?


PS: You got me hooked on smileys

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[txjump]

well, if its declared globally or as a class member isnt it on the heap? and if its local to a function its on the stack?

if thats correct, then it works when its on the stack but not on the heap.


ps: i love the smileys too...add a little color

 

[qednick]

No, one is created:

[tt]CDialog aDlg;
if (aDlg.DoModal()==IDOK) {...}[/tt]

the other is:

[tt]CDialog* aDlg = new CDialog;
if (aDlg->DoModal()==IDOK) {...}
// then when we've finished with it...
delete aDlg;
[/tt]

I think what's happening is that you are creating the dialog in a function. It is then somehow going out of scope when DestroyWindow is called from a different area.
Try using the pointer and don't delete it until you know for sure the dialog is destroyed.

PS: Have a pumpkin for halloween on me!

PPS: Are you in Texas?

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[txjump]

cool, i will try that, thanks. you are right i bet that it has lost scope sometime.

i created the instance as a member variable in the dll...setting a few things along the way and then actually calling domodal a little later.

woooohoooo...thanks for the pumpkin!

yep, im in texas...where are you?
;-)

 

[qednick]

I'm in Tomball just north of Houston. Move here from England two years ago.

May the force be with you

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[txjump]

were you born in England?

im in dallas...born in california but been in texas since i was 4. yeee haw

 

[qednick]

yep, born and raised in West Yorkshire which is about 200 miles north of London. Moving to Centerville next summer so I guess I'll have to drive into Dallas to visit Saltgrass!


Are you working as a programmer in Dallas?

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[txjump]

yummy, saltgrass!
i know its a steak place but they have the best bacon cheeseburgers around!

why are you moving to centerville?

yes, im working as a programmer here in dallas. (and as if you couldnt tell, im still new at this msvc++ thing)

txjump

 

[txjump]

just outta curiosity...

the pointer example you gave before, it works as long as the new is in the same function. the minute i try to instantiate it elsewhere, the assertion error happens. its really not a big deal cause i can definately work around that, but i was just wondering if i was doing something wrong by trying to create a dialog instance in one function and call the domodal from another (even using a pointer).

thanks for helping me...i really do appreciate it. ive had some great help from these tek-tips forums.

 

[qednick]

It's hard to say without seeing all your project files exactly where things are going wrong. If you can work around it though I guess it's not such a big deal.

I just bought 12 acres in Centerville through the VLB - real cheap!! 100% owner finance at $140 a month no credit checks whatsoever.

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[txjump]

that sounds like a great deal...hope you enjoy it!

 

[qednick]

Yeppers! We had a Halloween party last night but my pumpkin got drunk....

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[robtromp]

Hi,

I am seeing the same problem in my application. Did you ever resolve it? It seems odd that if you ignore the assertion, everything works fine. Seems like it might be a bug in MFC, related to using dialogs that are defined in a different DLL than the main app.

Thanks,

Rob

 

[txjump]

hi robtromp,

i just did a work around ... but i read in some documentation somewhere that a dialog is always created on the stack. always. so qednick was probably right that the scope gets lost. even when i tried to use it as a pointer, i got the same results.

so i just created the dialog when i needed it as local object in my member function, instead of trying to create it early as an object in my class and initialize along the way.

txjump

 

[robtromp]

Hi txjump,
Thanks for getting back to me on this! I was hoping you had found another way around this, as this one will force the folks who write the DLL's that have the dialogs to rewrite some of their code (they do some initialization before passing me the dialog object). Oh well, shouldn't be too big a deal for them...

Thanks again,

Rob

 

[txjump]

have the dlls already been used by someone successfully? if so, maybe they have some sample code that does work.

im still new to dlls (and actually windows programming) so perhaps they know how to do it as a class member.

good luck

 

[robtromp]

Hi,
THe DLL's are basically from projects that used to be separate applications, but are now being integrated into my IDE. Their dialogs were working fine before. My impression from tracing through the MFC code is that when the dialog is creatred in the DLL, it does not get added to the application's window map, causing a different execution path to be taken in DoModal() that results in the assertion. Unfortunately, I don't see any easy way to make sure the dialog is added to this map before calling DoModal, as I haven't been able to find where windows are added to the map. I'll let you know if I come up with a solution, but I'm afraid I won't be able to spend much more time on this problem.

Regards,

Rob

 

[txjump]

MFC code tracing is beyond me at this moment i think but i found an article talking about window maps and such:

http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0997/c++0997.htm&nav=/msj/0997/newnav.htm

he has the source code to a viewer that you can use to check out the permanent and temporary maps.

since i dont need it right now, i probably wont spend anymore time on it either, but the article has some interesting comments.

txjump

 

[robtromp]

Thanx for the link! Looks like an intereting article. The DLL developers are OK with me creating a new object locally, so I'll probably just do the workaround...

Take care,

Rob