Re: Dialog, Custom Controls and Extension DLLs...

From:

KD <keith.degrace@gmail.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Thu, 29 May 2008 08:33:17 -0700 (PDT)

Message-ID:

<4142994d-0d22-47ea-895e-a3b318b0c14a@t54g2000hsg.googlegroups.com>

My extension DLLs are built using the same DllMain template as the
ones generated by the AppWizard. I dumbed it down for this post, but
there are many other dialogs, controls (not custom control) and
resources that interact across those DLLs and everything else works
fine. The problem is very specific to this scenario. It also worked
fine before I started using extension DLLs. I would think it has
something to do with this comment in MSDN for the return value of
AfxGetInstanceHandle():

Return Value
An HINSTANCE to the current instance of the application. If called
from within a DLL linked with the USRDLL version of MFC, an HINSTANCE
to the DLL is returned.

The thing I don't understand is why this behavior change in
AfxGetInstanceHandle() when called from an extension DLL? And is
there a general way to get the HINSTANCE of the DLL where the function
is called from, regardless if it is regular or extension?

KD

On May 29, 10:55 am, "Ajay Kalra" <ajayka...@yahoo.com> wrote:

In an Extension DLL, you have to make sure that you provide the mechanism
for locating resources that are present in other modules and needed by
Extension DLL. I have CDynLinkLibrary to do this, which is to build a
resource chain that is searched by your module when it needs the resources.
Others have used AfxSetResourceHandle successfully. That will be something
to look into.

--
Ajay

"KD" <keith.degr...@gmail.com> wrote in message

news:35d0b5f2-bdd2-4274-9a75-01408742d4b6@k13g2000hse.googlegroups.com...

I am trying to convert our DLLs from Regular to Extension, and I ran
into a problem where Create() is now failing for one of my dialogs.
I've narrowed it down to the fact that this dialog has a custom
control. The custom control class is imported from a DLL. Here is
the scenario in more detail:

In DLL1, I have the dialog and code that tries to create it...

class Dialog
{
   CustomControl customControl;
};

void onSomeMessage()
{
   Dialog.Create(IDD_OF_A_DIALOG_RESOURCE_DEFINED_IN_DLL1);
}

In DLL2, I have an exported custom control that looks like this...

class DLL2_API CustomControl
{
   CustomControl()
   {
       WNDCLASS wndClass;
       HINSTANCE hInst = AfxGetInstanceHandle();

       if (!::GetClassInfo(hInst, CLASSNAME, &wndClass))
       {
           wndClass.lpfnWndProc = ::DefWindowProc;
           wndClass.cbClsExtra = wndClass.cbWndExtra = 0;
           wndClass.hInstance = hInst;
           wndClass.hIcon = NULL;
           wndClass.hCursor = AfxGetApp()-

LoadStandardCursor(IDC_ARROW);

           wndClass.hbrBackground = NULL;
           wndClass.lpszMenuName = NULL;
           wndClass.lpszClassName = CLASSNAME;

           if (!AfxRegisterClass(&wndClass))
               AfxThrowResourceException();
       }
   }
};

So far, my focus has been on the call to AfxGetInstanceHandle().
After a bit of research, I saw a post about AfxGetResourceHandle(). I
tried this call instead, but the return value is no different. In
both calls, the return value was the hInstance of the exe. The last
thing I've tried, which seems to have worked, was to use DLL1's
hInstance. The problem is that I hardcoded the value. I'm looking
for the proper solution, not a hack.

Has anyone experienced this sort of problem?

Thanks,
KD