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?
| Вернуться в корень Архива |