Resource files in Visual Studio

[Oskar Wåglund]

Hi,

I am trying to get the resource files from an old Borland project to work with Visual Studio 2013, but I can't quite grasp the .rh files that were used in the old project. Are they at all compatible with the new environment, or should I convert them to .h files? Visual Studio doesn't even seem capable of reading them as of now.

I have some support from the thread "[OwlNExt-users] port to Visual Studio, pls help" from 2007, but I appreciate any additional tips that you may have!

Thank you
Oskar

[Vidar Hasfjord]

Hi Oskar,

Whether the resource file headers use ".rh" or ".h" extension has no bearing on the conversion process (OWLNext uses ".rh", as you can see under "include/owl/*.rh"). The important matter is the contents of the files, in particular the differences between the Borland and Microsoft resource file formats.

See Converting Borland C++ Resource Files to Visual C++.

If you have particular resource compilation errors, please post the details. And it is always helpful if you can post the actual code you are struggling with.

PS. To see resource file use in action in an actual example, see e.g. "examples/apps/replaceplus".

[Oskar Wåglund]

Hi Vidar,

Sorry for my vague question! The problem is that VS13 gives fatal error RC1015: cannot open include file 'util.rh', whenever I try to look at the resources in the "Resource View", but perhaps that is of less importance. It seems like the files are found at compile time at least!

Resource includes does not work either; The operation could not be completed, access denied.

So to clarify: can I have one built .rc file per project, or per solution (23 projects in this case)? And can I just include the other .rc files into the the "main" .rc file, while ensuring that no colllisions occur?

//Oskar

[Vidar Hasfjord]

cannot open include file 'util.rh' [in "Resource View"]

Ah, now I see. That has to do with the directory settings. See Configuration Properties | Resources | General | Additional Include Directories. For example, for the included examples, such as "examples/apps/replaceplus" set this to "..\..\..\include". For your own project you can use "$(OWLROOT)\include".

Note that, for OWLNext itself and our examples, editing of resources using Resource View is disabled by design, as not to corrupt the resources in a non-portable way between compilers. See FAQ.

Resource includes does not work either; The operation could not be completed, access denied.

I assume this is related to the issue described above in the FAQ. If you want to use Resource View for editing, try creating a new resource file, and then copy resources over, as described in the FAQ. This new file will be fully generated code by Resource View, so should not have any limitations.

So to clarify: can I have one built .rc file per project, or per solution (23 projects in this case)? And can I just include the other .rc files into the the "main" .rc file, while ensuring that no colllisions occur?

Resources (i.e. dialog IDs, string IDs, etc.) of course need to be unique within an application. But there is not a limit on how many RC-files you can add to a project (although it used to be in old versions of Visual Studio, which only allowed one resource file per application).

[Oskar Wåglund]

Resources (i.e. dialog IDs, string IDs, etc.) of course need to be unique within an application. But there is not a limit on how many RC-files you can add to a project (although it used to be in old versions of Visual Studio, which only allowed one resource file per application).

The reason I'm wondering is because you wrote in the thread from 2007 that

While you can have many resource files, Microsoft Visual Studio operates with one master resource file that must include everything else. At least this was the case in VC6, although I have not checked since.
You can put all your RC files into the project (the Solution Explorer) but you must mark all but one, the master file, as excluded from the build. You include the other resource files into the master using ordinary include statements.

So that barrier has been removed now? That's good! :)

Thank you again, I will try to make some sense of this now!

//Oskar

[Vidar Hasfjord]

So that barrier [of one resource file per project] has been removed now?

Yes. See my follow-up in the 2007 thread:

http://sourceforge.net/p/owlnext/mailman/message/6099852/