Microsoft KB Archive/150121

= PRB: MFC Loads Wrong Resource in Extension DLL =

Article ID: 150121

Article Last Modified on 11/21/2006

-

APPLIES TO

 Microsoft Foundation Class Library 4.2, when used with:  Microsoft Visual C++ 1.0 Professional Edition

 Microsoft Visual C++ 1.5 Professional Edition

 Microsoft Visual C++ 1.51

 Microsoft Visual C++ 1.52 Professional Edition</li></ul>

 Microsoft Visual C++ 2.0 Professional Edition</li></ul>

 Microsoft Visual C++ 2.1</li></ul>

 Microsoft Visual C++ 2.2</li></ul>

 Microsoft Visual C++ 4.0 Standard Edition</li></ul>

 Microsoft Visual C++ 4.1 Subscription</li></ul>

 Microsoft Visual C++ 4.2 Enterprise Edition</li></ul>

 Microsoft Visual C++ 4.2 Professional Edition</li></ul>

 Microsoft Visual C++ 5.0 Enterprise Edition</li></ul>

<ul> <li>Microsoft Visual C++ 5.0 Professional Edition</li></ul>

<ul> <li>Microsoft Visual C++ 6.0 Enterprise Edition</li></ul>

<ul> <li>Microsoft Visual C++ 6.0 Professional Edition</li></ul>

<ul> <li>Microsoft Visual C++ 6.0 Standard Edition</li></ul> </li></ul>

-

<div class="notice_section">

This article was previously published under Q150121

<div class="symptoms_section">

SYMPTOMS
The wrong resource is loaded when CBitmap::LoadBitmap, CMenu::LoadMenu, CString::LoadString or any other MFC resource-loading function is called in an MFC extension DLL (AFXDLL). In some cases, a resource in the application is loaded instead of the appropriate resource in the extension DLL.

<div class="cause_section">

CAUSE
When a resource in the application or another extension DLL gets loaded instead of a resource in the current extension DLL, the cause is usually improper resource management. An MFC application and all of its extension DLLs are one global chain of resources. If there are multiple resources with the same ID value in any of the modules in the chain, MFC uses the first resource it finds with the desired ID value. The first resource is often found in the application, which is searched before any of the extension DLLs.

<div class="resolution_section">

RESOLUTION
Change the ID values of any resources that conflict so they are unique in both the application and any extension DLL that the application uses. These values are stored in the Resource.h file for each project and can be modified in the Resource Editor or AppStudio with the Resource Symbols command.

To ensure that modules do not use conflicting symbol values, reserve different ranges of ID values for each module in the 1 through 0x6FFFF range. Set the _APS_NEXT_RESOURCE_VALUE definition in the Resource.h file for each module to the low end of that module's range before creating any resources. The Resource Editor uses this symbol to determine the ID value of the next resource created.

This technique is documented in MFC Technical Note 35 and in the DLLHUSK sample included with Visual C++.

<div class="status_section">

STATUS
This behavior is by design.

<div class="moreinformation_section">

MORE INFORMATION
In .exe or .dll files that link to MFC dynamically, MFC resource-loading functions call AfxFindResourceHandle to obtain the handle of the module where a resource is located. AfxFindResourceHandle searches for resources by type and symbol value in:


 * The module returned by AfxGetResourceHandle. This is usually the application.
 * The extension DLLs through the chain of CDynLinkLibrary objects.
 * Any language-specific resource DLLs.
 * Any attached MFC system DLLs (MFCxx.dll, for example).

NOTE: Some 16-bit MFC resource loading functions do not call AfxFindResourceHandle, but instead use the value returned from AfxCurrentResourceHandle.

Each extension DLL creates, initializes, and then passes a CDynLinkLibrary object to AfxInitExtensionModule that places the DLL in the resource chain. AfxTermExtensionModule removes the DLL from the chain when the DLL is detached from the application.

A benefit of this design is that MFC automatically locates a resource for an application or extension DLL, even if that resource is located in a distant extension DLL or the application itself. All resources in the process are chained, so ID values are passed between DLLs and the application and the proper resources are loaded. A disadvantage is that there are no duplicate ID values between any of the extension DLLs or the application that uses them.

To set the default location where AfxFindResourceHandle first checks for a resource, use AfxSetResourceHandle. Because AfxFindResourceHandle first checks the handle set by AfxSetResourceHandle, it can be used to circumvent the chain and load a resource from one particular DLL or application. The resource handle is restored to its original value immediately after loading the resources. The current default resource handle is found with AfxGetResourceHandle.

The DLLHUSK sample included with Visual C++ also illustrates this technique. In Testdll2.cpp, CListOutputFrame::Create sets the resource handle to the module handle stored in the AFX_EXTENSION_MODULE structure extension DLL. This structure is initialized with the module handle when it is passed to the CDynLinkLibrary constructor in InitTestDLL2.

<div class="references_section">