Baffling CDialog Problem

[Art Schumer]

Configuration: P400, NT 4.0Sp4 Workstation, VC6.0

I have a dialog that is common to two programs located in a DLL that I wrote. When I run one program it brings up the dialog just fine. When I run the other, I get an ASSERT within the MFC code CDataExchange::PrepareCtrl. It claims there isn't a data exchange control with an ID of 2020 (my first control in the dialog). I thought maybe the DLL's resource map was not hooked up the application properly however other dialogs in the DLL come up just fine in both programs.

The code to call up the dialog is identical between the two program as follows:

void CMainFrame::OnSetngsWorkerDB()
{
CWorkerDBDlg wrkrDlg;

wrkrDlg.DoModal();
}

Can anyone give me some help tracking this down? This baffles the &*^&%^ out of me!

thx, Art

=========================================
MFC code in dlgdata.cpp
=========================================

HWND CDataExchange::PrepareCtrl(int nIDC)
{
ASSERT(nIDC != 0);
ASSERT(nIDC != -1); // not allowed
HWND hWndCtrl;
m_pDlgWnd->GetDlgItem(nIDC, &hWndCtrl);
if (hWndCtrl == NULL)
{
***>>> DIES HERE <<<***
TRACE1("Error: no data exchange control with ID 0x%04X.\n", nIDC);
ASSERT(FALSE);
AfxThrowNotSupportedException();
}
m_hWndLastControl = hWndCtrl;
m_bEditLastControl = FALSE; // not an edit item by default
ASSERT(hWndCtrl != NULL); // never return NULL handle
return hWndCtrl;
}


Art Schumer
Evergreen Software, Inc.
<mailto: Art.Schumer@WorldNet.Att.Net>

[Paul McKenzie]

Did the dialog ever work in both programs? I ask this because I have had the experience of not recompiling all of my programs that share the same resources if my resources were changed. Needless to say, I would get invalid DDX errors.

I would "Build All" both programs and see if the problem goes away.

Regards,

Paul McKenzie

[Art Schumer]

Sure... I've rebuilt lots of time. I've tracked in the MFC code and it's looking for the correct item ID but it can't find it for some reason. That's why I suspected a problem with the resource map.

-Art

Art Schumer
Evergreen Software, Inc.
<mailto: Art.Schumer@WorldNet.Att.Net>

[Gomez Addams]

Did you add a little snippet that looks something like this ?

//\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\

static AFX_EXTENSION_MODULE NEAR extensionDLL = { NULL, NULL };


extern "C" int APIENTRY
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
if( dwReason == DLL_PROCESS_ATTACH )
{
// Extension DLL one-time initialization - do not obtain memory here,
// use the TRACE or ASSERT macros or call MessageBox
if( ! AfxInitExtensionModule(extensionDLL, hInstance) )
return 0;
}
return 1; // ok
}

// Exported DLL initialization is run in context of running application

#ifdef _DEBUG
__declspec(dllexport) void WINAPI dbgInitMfcLib()
#else // _DEBUG
__declspec(dllexport) void WINAPI relInitMfcLib()
#endif // _DEBUG
{
// create a new CDynLinkLibrary for this app
new CDynLinkLibrary(extensionDLL);
// nothing more to do
}


// in the header I have this :

#ifdef _DEBUG
__declspec(dllimport) void WINAPI dbgInitMfcLib()
#define InitMfcLib dbgInitMfcLib
#else // _DEBUG
__declspec(dllimport) void WINAPI relInitMfcLib()
#define InitMfcLib relInitMfcLib
#endif // _DEBUG

Then call InitMfcLib in the application. I do this to prevent mixed build
type errors. I could change library names but I figured this out first.
The function call has the effect of loading the DLL's module instance
into the extension list and might fix your problem. If you trace into the
MFC LoadModule function (AfxLoadModule I think) you will see that it
looks at this list for instances to examine for resources.

[Art Schumer]

It turned out to be two dialogs having the same ID number. Kind oif a bone head problem but I guess I don't have a lot of experience with DLLs.

Thanks all for the help!

-Art