[RESOLVED] Unable to load dialog holding webbrowser control from MFC Dll

Hello guys;
I am having a problem trying to load a dialog (dialog was created using VC++ 6 Resource editor) that resides inside an MFC DLL. Why MFC? Well... there's the catch! Turns out I need this dialog to hold a MS WebBrowser ActiveX Control.
The second requirement is that the calling program is (and has to remain) a plain Win32 App, so, this app will call the DLL holding the dialog and will show a browser in it.
In order to make things easier, I developed a small class that encapsulates the DLL's functionallity. This part works fine, but I provide the code for it to explain myself better:

/////////////////////////////////////////////
class __declspec ( dllimport ) MyBrowser
{
public:
MyBrowser ();
virtual ~MyBrowser ();

BOOL Show ();
};
/////////////////////////////////////////////

The important part is actually the Show() method which I provide next:

//implementation of MyBrowser::Show() inside DLL
/////////////////////////////////////////////
BOOL MyBrowser::Show ()
{
AFX_MANAGE_STATE ( AfxGetStaticModuleState () );
CMyBrowserDlg dlg;
int res = dlg.DoModal ();

if ( res == IDOK )
{
}
else if ( res == IDCANCEL )
{
}

return FALSE;
}
/////////////////////////////////////////////

Nothing special but a simple call to the dialog's constructor (which is generated by the VC++ wizard) and then...dlg.DoModal() !!!!!
Turns out that the call to DoModal() fails (returns -1), but ONLY WHEN THE DIALOG HOLDS THE WEBBROWSER CONTROL!!!
When I take the control out, DoModal() doesn't fail and the dialog shows perfectly!

Please help me!
Thanks in advance!

The typical cause for a -1 return code from DoModal is the inability to find the dialog resource. This is usually caused by not setting the resource handle to the correct module. You should be able to verify this rather easily if you step through the MFC code.

BTW, are you aware that you do not need to host a web browser control to display a web page?

Hello mike;

I went through the code and yes, it finds the resource. I think I might have found the problem, but I would like to know what other approach can I use. (you mentioned I don't need to host a webbrowser to display a web page). I actually ended up using this method because of the architecture I'm obligated to use. (calling app is a plain win32).

As a matter of fact, when the requirement for the browser arised, I did some research and realized that this might be the easiest, fastest approach :P ,but if there's something better... I will gladly use it.

Thanks-

You can use the Windows Shell to open the web page. Take a look at ShellExecute.

Yep...that might work too... :D ...and... it might be even easier that my approach ! ;)
Thanks Mike !!!

SOLUTION FOUND!
Just posting the solution I found in order to do a "Public Service" since the thread has been visited several times now.
Actually, the solution is quite simple...I will try to explain it as detailed as posible.
Something the VC wizard will not do for you automatically ON PROYECT CREATION is to set the InitInstance() method of the DLLApp. You shoud do that yourself but it's quite easy with the IDE. Just go to class view in your project, right click in your DLLApp class. Choose Add Virtual Function->InitInstance->AddHandle->Ok. This will create the method for you and all you need to insert in this new method is:
------------------------------------------
{
// TODO: Add your specialized code here and/or call the base class

AfxEnableControlContainer (); //INSERT THIS

CoInitialize(NULL); //INSERT THIS

return CWinApp::InitInstance();
}
-------------------------------------------
also, you need to uninitialize the instance, so follow the same steps pointed to insert the InitInstance method, but now insert the "ExitInstance()" method. In this method, insert the next line:
-------------------------------------------
{
// TODO: Add your specialized code here and/or call the base class
CoUninitialize(); //INSERT THIS

return CWinApp::ExitInstance();
}
-------------------------------------------
and that's it!

I know that there is a function called "AfxOleInit()" that is supposed to be used instead of CoInitialize (), and that using it prevents the need of using CoUninitialize(), however, I used this function for 3 days and it wasn't until I took the decision of testing CoInitialize() and take out the call to AfxOleInit() that the DLL actually worked.
So that's the solution. Don't ask me why the AfxOleInit() didn't work and the CoInitialize() did. I just know it worked and if someone knows the reason for this strange behaviour then please post it here.

BTW...thanks mike for your help.

Thanks and happy coding everyone!