Click here to Skip to main content
15,506,552 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have a Visual Studio project (C++) which uses a satellite DLL for language dependent resources. When I add a new resource to the main project and copy it to the satellite DLL project, magically the IDs seem to get assigned the same numerical value even though there are two separate resource.h files. I have cold sweats thinking of some time in the future when the IDs will be assigned different values and it all falls over - especially if I need to renumber the resources.

Do I need to worry, and if so, what would be the best way to ensure they are always kept the same?

I have read some interesting articles on this site about this but I still don't get it.

What I have tried:

I have tried including the main project's resource.h in the read-only symbol directives of the satellite resource.h (#include "..\resource.h") but sometimes when I rebuild, the resource compiler changes the code to something that has a syntax error in it (it removes the training quote mark from the included file)
Posted
Updated 19-Sep-18 21:57pm

The only way to do it is to have the value in only one header that is included in both places. I do this and it is working well for me when I do this.

One thing to consider is do the DLL's resource IDs really have to be visible in the app's resource file? I can't think of a case where they do. I realize it can make some things much more convenient but it is not absolutely necessary. This means you should try removing the inclusion of the library's Resource.h file from the app's resource file. Resource IDs can be the same in the DLL and the app and there are some functions that allow you to select the handle to use for resource lookups which resolves those issues.

In my newer apps I make a special effort to have the resource IDs visible to as few modules as possible. In fact, my dialog handling code does not have any header files. There is an interface defined that does not involve ANY resource IDs. If you think about it, why should there be? Only the specific code that manages the dialog needs them. The code that invokes the dialog doesn't. All it needs to do is call a function and pass it some data and the parent window. The dialog handling code manages all of the data for the app. The app doesn't need to know about every control in the dialog and what type of objects they are or anything else about the dialog like its ID. That doesn't matter to the app because it doesn't use the ID for anything.
 
Share this answer
 
Comments
softwaremonkey 20-Sep-18 3:18am    
Thanks Richard. I may have confused you with my rambling explanation. The main app doesn't include the resource DLL's resource.h file but rather the other way round. I did this in an attempt to keep the IDs the same but Visual Studio always wants to add the IDs of new resources to the DLLs own resource.h.

I may have gone about this the wrong way but all of my translated texts are in a string table and so these IDs need to be 'available' to quite a lot of modules. Perhaps there is a better way maybe?
This isnt magic but some built in functionality. You see some values in the of the resource header which provide that information. It can go wrong - I had such cases and they may really hard to detect. So avoid playing that game. ;-)

As Richards wrote it is best to use only one resource.h header. That implies the discipline to work only on the main header and than copy it to the sub project. Dont ferget to work on the changed resource data.

If really need to work with some edge case than you can you the rc2 file which isnt tracked.
 
Share this answer
 
Comments
softwaremonkey 20-Sep-18 3:12am    
Thanks to both yourself and Richard for your reply. So are you saying that if I add a new resource to the main app, then copy the resource to the DLL I should then simply 'overwrite' the DLL's resource.h with the one from the main app? That sounds easy enough to do!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900