[RESOLVED] Getting a dialog to function in a DLL

[Mike Pliam]

I have a Regurlar MFC DLL. The DLL is called from an MFC app using early binding (library and header included in app compile). I would like the client to select from options presented in a dialog generated from within the DLL. In this case, the dialog is called by the DLL code and NOT by the client code.

I've tried this. It compiles but crashes with error:

	AFX_MANAGE_STATE(AfxGetStaticModuleState( ));
	CTestDlg dlg(AfxGetMainWnd());
	dlg.DoModal();

with error code in objcore.cpp:

BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
{
==>	ENSURE(this != NULL);
	// it better be in valid memory, at least for CObject size
	ASSERT(AfxIsValidAddress(this, sizeof(CObject)));

	// simple SI case
	CRuntimeClass* pClassThis = GetRuntimeClass();

	ENSURE(pClassThis);
	return pClassThis->IsDerivedFrom(pClass);
}

What's going on here?

[Igor Vartanov]

Mike, you have a debugger in your VS. So please take a look at the call stack and try to analyze it. I'm looking forward to your theories.

BTW, are you sure AfxGetMainWnd() returns something valid?

[Mike Pliam]

The call stack doesnt tell me much more. Here's the tail end before the crash:

> mfc100d.dll!CObject::IsKindOf(const CRuntimeClass * pClass) Line 40 + 0x22 bytes C++
mfc100d.dll!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate, CWnd * pParentWnd, HINSTANCE__ * hInst) Line 292 + 0x12 bytes C++
mfc100d.dll!CDialog:oModal() Line 630 + 0x20 bytes C++
mstats.dll!Descriptives2(double * * pf, char * varlist, char * outfilename) Line 86 C++
clap32.dll!CParser:escriptives() Line 4223 + 0x24 bytes C++

And in this context, AfxGetMainWnd() returns NULL !

Apparently a 'this' is missing.

I should add that the dialog was added using the resource editor in the usual manner and the class CTestDlg was obtained by double clicking on the dialog. Also, I changed the CTestDlg ctor to conform to that of our previous conversations. Also, I eliminated the CTestDlg dtor.

I'm not sure where to go from here.

[Igor Vartanov]

The very first candidate in CreateDlgIndirect is:

	if ( AfxGetApp()->IsKindOf( RUNTIME_CLASS( COleControlModule ) ) )

From what I can gather you most probably missed to define app object in your dll. Again. You must remember we discussed that quite recently.

[Mike Pliam]

I do not think that this problem is similar to the one we discussed recently, mainly because it is the DLL itself calling up a dialog, and not the app that called the DLL. But I admit that I am uncertain about this.

Not the only one to note this problem:

Can't create modal dialog from MFC DLL
http://stackoverflow.com/questions/6...g-from-mfc-dll

But no workable answer forthcoming.

[Mike Pliam]

The answer turns out to be a simple one:

This works:

	AFX_MANAGE_STATE(AfxGetStaticModuleState( ));
	CTestDlg dlg;
	dlg.DoModal();

NB: If you comment out AFX_MANAGE_STATE(AfxGetStaticModuleState( ));, Function1 still works but no dialog appears.


The attached demo proves it. I think I was confused by our earlier discussions and the postings of others.

[Igor Vartanov]

Mike, it seems you fixed the problem somehow but have not realized what exactly was the problem. Your "This works" snippet differs from original one only in not providing explicit dialog parent, while originally it was AfxGetMainWnd() there. Now, if you put that back, your dialog runs the same without any problem.

Now to what really matters. In your dll code (dlg.cpp) you have CWinApp object defined. When I comment it out, I precisely obtain the assertion exception inside CObject::IsKindOf, and the call stack identical to yours. So I believe this confirms my "very first candidate" comment. It seems the said app object appeared there after some of your experiments, at the same time when _tmain appeared somehow in the dll code (where it actually does not belong and therefore can be just thrown away ).

[Mike Pliam]

Igor, your suggestion to test what AfxGetMainWnd() returns was the key. In fact, in the original context, it returned NULL. So simply leaving it out of the CTextDlg initialization solved the problem. I remain unclear as to which 'main window' the AfxGetMainWnd() function refers to in the DLL. Is it the DLL theApp or is it the main window of the DLL client app? Or does it depend upon how and where it's called?

[Igor Vartanov]

No, it turns out it wasn't a key. You initially provided no project to look in, so I asked for some details which finally appeared irrelevant. Returning NULL actually is equivalent to your current code where NULL is automatically implied by constructor.

Please re-read my comments again. If it was the key, returning AfxGetMainWnd back in place would replicate your initial problem. But it doesn't.

And it doesn't matter what the main window is in this particular case, as your initial problem has nothing to do with main window, or dialog parent window.

[Mike Pliam]

You're quite correct, Igor. I have searched high and low for my earlier code, but I cannot find it, nor can I reproduce the earlier error. I suspect I did something stupid in the original code and misinterpreted the nature of the problem. In any case, the most recent demo seems to work. Thanks for you input. I apologize if I wasted your time.

[Igor Vartanov]

No problem, really. This just confirms how the point of providing minimal but compilable project is important for decent investigation of a problem.