• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1094
  • Last Modified:

Using MFC Dialog in a Win32 DLL

I want to use the U.I. of MFC to create a Dialog Box as
part of a generic win32 DLL.
 
Example: I have a win32 DLL that draws Graphs. I would like
 to be able to configure the graph by making a call to a
 member function of the DLL that pops up a configuration
 dialog.

My crude attempt appears that the DLL resources are not
accessible (DoModal() returns -1). Any suggestions?
0
rocco
Asked:
rocco
1 Solution
 
AVaulinCommented:
Be sure that you set resource handler to DLL before using dialog resource from this DLL. AfxSetResourceHadle function do this.
0
 
roccoAuthor Commented:
I have tried that. It did not make a difference. The DLL
was initial created as a win32 DLL, then adding the shared
MFC library. There seems to be a conflict when _USRDLL is
defined.
0
 
yonatCommented:
Call AFX_MANAGE_STATE(AfxGetStaticModuleState( )) before loading
resources:

// ...
AFX_MANAGE_STATE(AfxGetStaticModuleState( ))
MyDlg dlg;
int ret = dlg.DoModal();
// ...
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
roccoAuthor Commented:
That is true if the class is derived from CWinApp
(MFC dll). In doing so, you will get multiple declared
symbols (_DllMain@12).

I am starting with a generic C++ class (via Win32 dll)
and adding a MFC dialog (CDialog) to provide an GUI
interface. The attempt is to make UI classes separate
from the application classes (in this case the main DLL
class that calls a dialog through a member function.

0
 
rpbCommented:
If you derive a class from MFC (which you are doing here by having a class derive from CDialog) then you are extending the class hierarchy.  To get this to work you need to make sure you are building an MFC extension DLL.  I don't know if you can do it otherwise, because it will fail to load the resource.  MFC expects there to be an MFC "App" somewhere around to access information from, so if you build a DLL to be used generically, you need to make it an extension dll.

One other way to do this would be to override DoModal(), etc., and alter the way it loads the resource by explicitly loading it from the dll's resources (rather than the apps).  MFC walks down a line of CDynLinkLibrary objects to find resources, unless you use the AFX_MANAGE_STATE macro mentioned earlier.  You could override the dialog-template loading and load it yourself, but this may mean copying a chunk of code out of MFC and making a few tweaks in your version.  If you find the bit that is failing then you can just modify that bit, and assuming it is the resource-loading then that can be patched to load the correct template.

It's probably this bit at the top of DoModal():

  hInst = AfxFindResourceHandle(m_lpszTemplateName, RT_DIALOG);
  HRSRC hResource = ::FindResource(hInst, m_lpszTemplateName, RT_DIALOG);
  hDialogTemplate = LoadResource(hInst, hResource);

0
 
roccoAuthor Commented:
This sounds like were the problem lies. In order to create a
DLL that support a MFC Dialog, some kind of "App" needs to
be made available. In an extension DLL, the Application's
App class is used. For a regular MFC DLL, the DLL is derived
from CWinApp. Which gets into the reason I work from the Win32
DLL side, keeping the MFC code to a limited area... Any suggestion?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Tackle projects and never again get stuck behind a technical roadblock.
Join Now