Extension DLL string resources
Thomas Fonseca/FASTTAX
Wednesday, December 11, 1996
Environment: VC++ 1.52, MFC 2.50, Win3.1, Win95.
Book Reference: Inside Visual C++ version 1.5
I have an extension dll that contains its own resources, both string and dialog
resources.
I linked it in and was calling it from the Client EXE, setting the resource
handle with
"AfxSetResourceHandle(extensionDLL.hModule)" just prior to calling the DLL's
exported
dialog.DoModal routine. I set it up just as described in the book "Inside
Visual C++
version 1.5" chapter 26 page 653.
Everything worked as advertised. I then changed one AfxMessage parameter in
the DLL
from a quoted string to a string ID defined in the DLL's string table and at
that point I began getting
an Assert on line 41 of the mfc's DLGDATA.CPP file. Followed by another Assert
in vbctrl.cpp and a GPF!
This AfxMessage call is not executed - it is in a member that has not yet been
called.
Apparently the program could no longer locate the list box associated with the
DLLs dialog ID 102.
Both the client exe and the extension dll have string tables and dialogs
defined and sure
enough they both have a dialog resource ID 102 but the ID for the string
resource is unique to the DLL.
After a little more tracing I found that the Assert was triggered because the
program was now loading
the EXE's dialog 102 which does not have a list box defined - so naturally the
program could not
load it. I then replaced the string ID parameter with a quoted string when I
call the AfxMessage
and once again, the correct dialog 102, defined in the extension DLL's resource
file, was loaded and
the asserts and GPF did not occur.
In short - AfxFindResourceHandle locates the dialog defined in a DLL resource
set by AfxSetResourceHandle.
Add a string table reference and AfxSetResourceHandle now looks in the EXE's
resources first!
I don't understand how passing a string resource to AfxMessage is causing the
incorrect resource file
to be searched first, especially since this code is not even executed?
Robert H. Mowery III -- rmowery@msn.com
Saturday, December 14, 1996
You need to give your resources unique ID's. The same resource ID's in one
extension cannot be used as an ID in another extension or in your EXE
resource. It sounds like you have the same resource ID #102 assigned to more
then one resource. Also be sure to check the ranges of the ID's you are using
since some are reserved by MFC.
-Robert Mowery
----------
From: owner-mfc-l@majordomo.netcom.com on behalf of Thomas Fonseca/FASTTAX
Sent: Wednesday, December 11, 1996 9:39 AM
To: mfc-l
Cc: Ken Dinsmore/FASTTAX; Michael Henry
Subject: Extension DLL string resources
Environment: VC++ 1.52, MFC 2.50, Win3.1, Win95.
Book Reference: Inside Visual C++ version 1.5
I have an extension dll that contains its own resources, both string and
dialog
resources.
I linked it in and was calling it from the Client EXE, setting the resource
handle with
"AfxSetResourceHandle(extensionDLL.hModule)" just prior to calling the DLL's
exported
dialog.DoModal routine. I set it up just as described in the book "Inside
Visual C++
version 1.5" chapter 26 page 653.
Everything worked as advertised. I then changed one AfxMessage parameter in
the DLL
from a quoted string to a string ID defined in the DLL's string table and at
that point I began getting
an Assert on line 41 of the mfc's DLGDATA.CPP file. Followed by another
Assert
in vbctrl.cpp and a GPF!
This AfxMessage call is not executed - it is in a member that has not yet been
called.
Apparently the program could no longer locate the list box associated with the
DLLs dialog ID 102.
Both the client exe and the extension dll have string tables and dialogs
defined and sure
enough they both have a dialog resource ID 102 but the ID for the string
resource is unique to the DLL.
After a little more tracing I found that the Assert was triggered because the
program was now loading
the EXE's dialog 102 which does not have a list box defined - so naturally the
program could not
load it. I then replaced the string ID parameter with a quoted string when I
call the AfxMessage
and once again, the correct dialog 102, defined in the extension DLL's
resource
file, was loaded and
the asserts and GPF did not occur.
In short - AfxFindResourceHandle locates the dialog defined in a DLL resource
set by AfxSetResourceHandle.
Add a string table reference and AfxSetResourceHandle now looks in the EXE's
resources first!
I don't understand how passing a string resource to AfxMessage is causing the
incorrect resource file
to be searched first, especially since this code is not even executed?
| Вернуться в корень Архива
|