Resource id conflicts in DLLs and TN035
Al Margheim -- marghal@elwood.pionet.net
Monday, June 03, 1996
Environment: VC++ 4.1, WinNT 3.51 SP3
I too am looking for advice on an aspect of managing large Visual C++
projects with multiple developers.
Several months ago, to reduce programmer deadlock on the project .rc and
resource.h files, my group moved some of our dialog boxes into their own
dlls, with their own .rc files. This worked well until we added tooltips to
the project. Because the tooltip string resources have the same resource ids
as their associated controls and because some of the controls in the
different dialogs have the same resource ids, we sometimes see the wrong
text displayed in a tooltip.
I've read tech note TN035 so I know that one solution to this problem is to
assign a unique range of resource ids to each .rc file using the _APS_NEXT
defines in resource.h. Has anyone else tried this? Does anyone know of any
problems that might arise as a result of implementing unique id ranges? Can
anyone suggest a better/different approach?
Some developers in our group are arguing that assigning ranges using the
_APS_NEXT defines will be unreliable, that we can't trust App Studio to
not change the id values arbitrarily. These developers are recommending
that we merge all of our resources back into one .rc file again, and I hate
to do that. It would be nice to know if anyone else has solved this
problem and what, if any, the trade-offs were.
Best regards,
Al Margheim
craigtt@ccmail.PE-Nelson.COM
Friday, June 07, 1996
We had the same problem where I previously worked. I went through and
assigned resource id's to each piece of the project. In itself, this
was somewhat of a pain since there were probably going to be about 40
DLLs in the system. We didn't have any problem with AppStudio not
using the correct ranges. However, it's difficult to decide how big a
range needs to be for each component ahead of time. Also, as the
project grows, you have to check to make sure that the id's in one
DLL's range haven't grown to the collision point with another DLL.
The automatic searching for resources through all the DLLs linked to
an application sounds nice, but as you've discovered, it leads to some
problems as well. Another solution is to develop your own scheme for
handling resources and know explicitly where to load them from but
that's some work too and adds a lot of coupling between components.
The MFC state information can help with this but it is not well
documented.
Using third party components also adds another dimension to the
problem as does writing your own base components that are shared
across multiple projects even in the same company.
Sorry I don't have a "good" solution to the problem right now but it's
a common problem and I hope the MFC development community can come up
with a reasonable solution or tweak MS into looking further into the
problem.
Tim Craig
PE-Nelson
______________________________ Reply Separator _________________________________
Subject: Resource id conflicts in DLLs and TN035
Author: mfc-l@netcom.com at SMTPLINK-PEN
Date: 6/7/96 10:09 AM
Environment: VC++ 4.1, WinNT 3.51 SP3
I too am looking for advice on an aspect of managing large Visual C++
projects with multiple developers.
Several months ago, to reduce programmer deadlock on the project .rc and
resource.h files, my group moved some of our dialog boxes into their own
dlls, with their own .rc files. This worked well until we added tooltips to
the project. Because the tooltip string resources have the same resource ids
as their associated controls and because some of the controls in the
different dialogs have the same resource ids, we sometimes see the wrong
text displayed in a tooltip.
I've read tech note TN035 so I know that one solution to this problem is to
assign a unique range of resource ids to each .rc file using the _APS_NEXT
defines in resource.h. Has anyone else tried this? Does anyone know of any
problems that might arise as a result of implementing unique id ranges? Can
anyone suggest a better/different approach?
Some developers in our group are arguing that assigning ranges using the
_APS_NEXT defines will be unreliable, that we can't trust App Studio to
not change the id values arbitrarily. These developers are recommending
that we merge all of our resources back into one .rc file again, and I hate
to do that. It would be nice to know if anyone else has solved this
problem and what, if any, the trade-offs were.
Best regards,
Al Margheim
| Вернуться в корень Архива
|