I have two .rc files for different languages which includes the same resource.h file. Whenever I am editing one .rc file it takes over the resource.h file and tries to modify it. Since the code in source controls, Visual Studio 2010 checks out both the .h file as well along with the .rc file that I want to edit.
You may want to share a header file between two .RC files that are in different projects, or possibly the same project. To do so, simply apply the Read-Only Directives technique described above to both .RC files.
I did that but it did nothing. How can I share the same resource.h in both resource (.rc) files without each vying to get control of resource.h file?
Did you try replacing ALL instances of "resource.h" with "yourfile.h"? I know in my .rc file there's more than one, but I only saw that article mention one.
Did you try replacing ALL instances of "resource.h" with "yourfile.h"? I know in my .rc file there's more than one, but I only saw that article mention one.
I don't have my own resource.h file, I need to share the main resource.h file in both .rc files. This is necessary because all typical resources like dialogs, menus's IDs are defined in resource.h
I am contemplating defining my own str_resource.h for only string IDs though but the drawback is that I wouldn't be able to use the IDE to define strings - well that seems almost a good thing but are there any potential issues if I assign the strings my own IDs rather let Visual Studio IDE assign it?
I don't have my own resource.h file, I need to share the main resource.h file in both .rc files. This is necessary because all typical resources like dialogs, menus's IDs are defined in resource.h
I am contemplating defining my own str_resource.h for only string IDs though but the drawback is that I wouldn't be able to use the IDE to define strings - well that seems almost a good thing but are there any potential issues if I assign the strings my own IDs rather let Visual Studio IDE assign it?
By your own file, I meant your own path. I'm assuming that the path of the shared resource file is different than just "resource.h" for at least one of the projects. So "resource.h" might turn into "C:\projects\project1\resource.h" or something.
Also, personally, I hate it when the IDE creates the IDs for me. It does a shitty job at it, which is why I have 1,000 IDs and only 150 IDs in use. And their cleanup program works like crap. You won't run into any issues at all if you create them yourself. (As long as they all have unique IDs. )
By your own file, I meant your own path. I'm assuming that the path of the shared resource file is different than just "resource.h" for at least one of the projects. So "resource.h" might turn into "C:\projects\project1\resource.h" or something.
Also, personally, I hate it when the IDE creates the IDs for me. It does a shitty job at it, which is why I have 1,000 IDs and only 150 IDs in use. And their cleanup program works like crap. You won't run into any issues at all if you create them yourself. (As long as they all have unique IDs. )
Right the path in 2nd resource is different, I did change all instance of resource.h with the new path in 2nd resource. Did you ever had similar issue or it is possible that 2nd resource doesn't modify the resource.h file?
Try using forward slashes '/'. They work just fine in Windows and will eliminate any escape character errors. Also, try using an absolute path ("C:/.../proj-main/resource.h"), just in case Windows doesn't like the ../ you're using.
I just tried this on a test project and it seemed to work. I had to replace 2 instances, one is in the include at the top, the other had "resource.h\0". I replaced resource.h with C:/..../resource.h in both instances and it worked.
Try using forward slashes '/'. They work just fine in Windows and will eliminate any escape character errors. Also, try using an absolute path ("C:/.../proj-main/resource.h"), just in case Windows doesn't like the ../ you're using.
I just tried this on a test project and it seemed to work. I had to replace 2 instances, one is in the include at the top, the other had "resource.h\0". I replaced resource.h with C:/..../resource.h in both instances and it worked.
I try various combinations and letting VS do what it wants. So in main include a single \ works fine but in TEXTINCLUDE clauses under two (\\) are required. At least this issue is resolved but I am still struggling to delink resource.h from 2nd rc file. Here is what I did.
Code:
1 TEXTINCLUDE
BEGIN
// "#include ""..\\proj-main\\resource.h""\r\n" (removed it)
END
Now it doesn't checkout or link to the resource.h file BUT it creates another resource.h file on its own in the same directory and include that one in the rc file. Obviously I don't want two resource.h files, Anyone knows how to stop that? Thanks.
To get rid of further painful headaches, avoid as much as possible manual editing of .rc file.
Instead, if you want to change resource symbol header file (by default, resource.h placed in the project folder), proceed as follows:
In "Resource View" window, right-click on resource file node and select "Resource Includes..." menu item.
In the "Resource Includes" dialog, change "resource.h" with anyone your muscles want (of course, with an existing one).
Next, the IDE will know better than you what is to correctly do.
To get rid of further painful headaches, avoid as much as possible manual editing of .rc file.
Instead, if you want to change resource symbol header file (by default, resource.h placed in the project folder), proceed as follows:
In "Resource View" window, right-click on resource file node and select "Resource Includes..." menu item.
In the "Resource Includes" dialog, change "resource.h" with anyone your muscles want (of course, with an existing one).
Next, the IDE will know better than you what is to correctly do.
See also the attached image.
Thanks I have already done that and I I go into resource include, it shows correct configuration.
The biggest problem is now is that rc file creates its own resource.h file in the same folder if I remove the linkage to the one in main project. Any suggestions regarding that? Thanks!
Probably, you still have some added by hand garbage in the .rc file. Just remove it. Also, to be sure, is good to close first the solution, delete some IDE-generated files, then open it again and do the steps I suggested above. And, of course, remove the old "include.h" from preject(s). And probably, you have to be sure that .rc or other involved files files are not overwritten somehow by the source safe version.
I made myself a solution with two projects sharing the same resource.h file and there is no problem.
Probably, you still have some added by hand garbage in the .rc file. Just remove it. Also, to be sure, is good to close first the solution, delete some IDE-generated files, then open it again and do the steps I suggested above. And, of course, remove the old "include.h" from preject(s). And probably, you have to be sure that .rc or other involved files files are not overwritten somehow by the source safe version.
I made myself a solution with two projects sharing the same resource.h file and there is no problem.
I just tried to repeat what you did and created a simple (no added code) solution with a main executable project and a dll project in one solution. Than I tried to use Resource Include to link the dll resource to the main resource.h file. This exercise completely overwrote the original resource.h file and the main application now obviously doesn't build. I have seen this happen to me in my original project as well.
The new content of the resource file is below where it basically deleted everything else. Note the 3rd line where it says Used by ...MyDll.rc now so it is claimed by the dll resource file now. I have attached the project.
Code:
//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by C:\Users\The.User\Documents\Visual Studio 2010\Projects\TestLang\Dll\Dll.rc
//
// Next default values for new objects
//
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE 4000
#define _APS_NEXT_COMMAND_VALUE 32771
#define _APS_NEXT_CONTROL_VALUE 4000
#define _APS_NEXT_SYMED_VALUE 4000
#endif
#endif
The image is also attached which shows the popup messages I get when I changed the resource file through Resource Include. The first popup is if I add ready only attribute to directive section. The 2nd is when the file is changed (by oMyDll.rc file), it now ask the main rc file needs to loaded again.
This behavior is basically totally consistent with my real application. I have had my original resource.h completely overwritten by the dll but thankfully everything is in source control there.
I am using Visual Studio 2010
Last edited by zspirit; June 1st, 2012 at 03:56 PM.
Both warnings are just informative and not a real reason to concern.
First one tells that you are going to do something unusual in a resource script file. Push "OK".
The other one tells that you are gong to modify a resource symbol header file which is also used in another project from your solution. Hit "Yes".
Both warnings are just informative and not a real reason to concern.
First one tells that you are going to do something unusual in a resource script file. Push "OK".
The other one tells that you are gong to modify a resource symbol header file which is also used in another project from your solution. Hit "Yes".
I did that but the biggest problem at hand is that latest active resource file takes ownership of the resource.h and may completely rewrite it. In the project I posted above, since the new .rc file in dll has nothing in it and resource.h has been rewritten and has almost nothing in it. I discovered the .rc file can't even be saved if I remove resource.h (through Resource Include command/menu)
Now I tried to fool the DLL's .rc file and linked it to a dummy.h as its resource file. I than added resource.h as ready only per documentation. This didn't help either since the .rc file recreated all resource IDs now in dummy.h but there is another copy of them in the main resource.h
Originally Posted by MSDN
The ID_TOOLS_SPELL symbol is kept in the shared header file, MYSHARED.H. You maintain this shared header file manually with a text editor; Visual C++ does not directly edit it. In the two resource files MYSTRS.RC and MYMENUS.RC, you specify #include MYSHARED.H in the Read-Only Directives for MYAPP.RC, using the Resource Includes command, as described earlier.
This indicates that the shared file between multiple .rc files must be edited in a text editor which make sense but resource.h which is always managed by the resource compiler - why can I share that!? The documentation doesn't say anything about it.
Here is a summary: The following should be the solution per available documentation only that it doesn't work at all.
Code:
1 TEXTINCLUDE
BEGIN
"resource.h\0"
END
2 TEXTINCLUDE
BEGIN
"#ifndef APSTUDIO_INVOKED\r\n"
"#include ""targetver.h""\r\n"
"#endif\r\n"
"#include ""afxres.h""\r\n"
"#include ""verrsrc.h""\r\n"
"#include ""..\\TestLang\\Resource.h""\r\n"
"\0"
END
The red part needs to be deleted, this would tell the resource compiler than this .rc file is not coupled with resource.h (in other words i will define my constant myself). The green line indicates to add resource.h from the project folder with ready only attribute (=don't modify it).
In reality this doesn't work. After this changes and making sure there is no mention of resource.h file in DLL's rc file but if I go to resource include command, it tells me somehow resource.h in the current folder is associated with it. This is proved by the fact if I add a new button to a dialog in DLL's .rc file, it generates the resource.h in the same folder with the new button ID as well as all other IDs in the resource file.
Something in resource compiler is telling it to create the resource.h file if no definition file is provided, I can't figure out where and there is hardly any documentation on this! Very frustrating!
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.