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