How to avoid resource identifier conflicts in Borland ObjectWindows .RC and .RH files

Summary:

By starting a new OWL project with standardized .RH and .RC files built from the resource code and predefined identifiers from all the predefined OWL resources, you avoid identifier conflicts later because the project is aware of the numeric values of all the identifiers from the beginning. 

For Borland C++ 4.0 and ObjectWindows Library OWL 2.0

It's been a long time since I used these files, so I cannot write about them with confidence that I still know what I'm talking about, but they address a problem that you might run into if you're working with OWL, so they might turn out to be useful.

Copyright (C)1999 Steven Whitney. Published under GNU GPL (General Public License) Version 3, with ABSOLUTELY NO WARRANTY.

What they are

2/16/06

An OWL (and Windows) project might use many resources such as menu items, command IDs, string resources, messages, graphics of various types, buttons, keyboard accelerators, predefined dialog boxes, and more. Each of these must be assigned a numeric identifier, either automatically or by you. The identifiers must be unique.

As you construct a project, creating resources for it, you simultaneously create the IDs. But OWL also has a number of predefined resources, with associated predefined IDs.

If you get halfway through a project and decide you want to use one of those predefined resources, the predefined IDs that have been created for them might conflict with ones you've already created, and resolving the conflicts can be difficult.

Furthermore, when you use the OWL-predefined resources in your program, Resource Workshop seems not to make a copy of them for use in that one project, but to use the centrally-located one that is part of the Borland OWL installation. Thus, if you modify any of those resources within Resource Workshop, you are modifying the master files, and your changes will apply to all your subsequent OWL program compilations, which could break your preexisting programs.

So I gathered together all the predefined OWL resources into a big resource file (OWLRES.RC) and gathered all their identifiers into a big resource header file (OWLRES.RH).

When starting a new project, I copied these files into the project directory, renamed them appropriately, and they became the starting RC and RH files for that project. Since they already contained all the OWL predefined resources, and since Resource Workshop would thereafter create only unique identifiers, there was no danger that I would later wind up with "identifier confusion" in the project.

Because all the OWL .rc and .rh files are copyrighted by Borland International, their actual text is not included here. Rather, I show you the process by which to create your own.

News! -- In support of the OWLNext project, the Borland spin-off company Embarcadero Technologies has released OWL, including source code and including the necessary resource headers, for download at http://cc.embarcadero.com/item/24574.

Instructions

5-28-00

Copy the files to your new project, renamed to be the .RC and .RH files for the project.

You can then be sure (I hope) that later additions to the project won't create any conflicts with existing resources or identifiers, since the project knew about all the predefined OWL ones from the start.

The above isn't quite true. Resource Compiler only seems to check for duplicate IDs within a single resource, not across all resources. Usually this is ok. But duplicate identifiers in concurrently running dialogs and/or windows seem able to cause bizarre application crashes due to misidentified notification or command messages flying about.

For example, a control with the same ID as a menu item may cause one window to execute the menu item command when an Executing dialog box may merely have been trying to draw the control. It seems to be a "good idea" to avoid all duplicate IDs at all times, but if you have multiple dialogs running at once, you MUST avoid all duplicate IDs at all times. I have had a lot of trouble any time I tried to use a dialog in a nonstandard way, and this may have been one of the reasons.

Any comments in the .RC (and .RH?) files may(?) be lost when the Resource Compiler alters or compiles the file, so it's usually not worth bothering adding comments.

//----------------------------------------------------------------------------

When creating a new resource file for a project, the order you do things is important. The default way Resource Compiler handles things is in many cases probably not what you want, so you have to set things up manually.

Assuming your project is PROJECT.IDE,

1. Copy OWLRES.RH and OWLRES.RC to PROJECT.RH and PROJECT.RC.
2. Use a text editor to modify PROJECT.RC so it #includes PROJECT.RH instead of OWLRES.RH.
3. Open PROJECT.RC in Resource Workshop, and specifically add PROJECT.RH to the project, so it knows to use this file for the identifiers, and not another file that it will create if you don't do this.
4. Add a new menu resource, and rename it MAINMENU. After you add any new menu item to it, you can delete the placeholder POPUP.
5. Add a new stringtable resource, and change the placeholder IDS_STRING1 to MAINMENU, so that will be the name of the stringtable.
6. Add a new accelerator table, and rename it MAINMENU. After you add any new accelerator, you can delete the placeholder CM_KEY101.
7. Add the line #include PROJECT.RH to any source file that needs to know the identifiers.

Customize the resulting files however needed.