Avoiding non-unique dialog control numbers

Avoiding non-unique dialog control numbers

The Visual Fortran resource compiler generates integers to match each dialog box control and collects these together in #define IDC_controlname = integer
statements in resource.h

I have found that the integer is not unique when all the controls for several dialog boxes are generated. That is, more than one control, if they are in seperate dialog boxes, can be assigned the same integer value. This is causing me problems in assigning a unique context help index to each control based on pairing the control integer with its help index.

Is there a way of setting up the resource compiler to avoid this duplication of control integers so that I do not have to go through the symbol table manually reassigning new unique integers to duplicates? If I add another dialog box, won't the problem reappear?

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Developer Studio maintains, in file resource.h, the "next available" control numbers in code similar to the following:

// Next default values for new objects
// 
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE        110
#define _APS_NEXT_COMMAND_VALUE         30003
#define _APS_NEXT_CONTROL_VALUE         1026
#define _APS_NEXT_SYMED_VALUE           101
#endif
#endif

My guess is that somehow Developer Studio is losing track of this, or perhaps this file was edited or reset somehow. Edit it appropriately and the problem should disappear.

Steve

Steve - Intel Developer Support

Steve,
Thanks for your reply.
When you say '... Edit it appropriately and the problem should disappear. ', there is the rub! What exactly is 'appropriate' for those _APS variables for any given resource.h?

Do I have to remove all my dialogs from the project, delete resource.h and then add the dialogs in one at a time, in order to build up a new copy of 'resource.h' (and associated resource.fd, script.rc, script.res)?

I think all you have to do is edit resource.h for a given project, and reset the "next" numbers to something higher than anything being used. Then, when you create new controls, they should get new numbers.

Steve

Steve - Intel Developer Support

Whenever you manually modify the .RC or Resource.h file, delete the .APS file in the project directory. The .APS file contains a "precompiled" version of your project's resources. Dev Studio will rebuild the .APS file the next time that you edit your resources. Otherwise, if Dev Studio decides that the .APS file doesn't need to be rebuilt, your manual changes will be lost.

Leo

Thanks, Leo, Steve, for the advice.
I finally created a new .RC resource file, with a new name, by copying resources from the old one, saving and recompiling. The resource.H file now contains no duplicate dialog control IDs.

For a while though, I found that subsequent changes I was making to dialogs were not being reflected in the built application. Then I discovered that the compiler was still producing a .RES file output with the old name, in the /release/ directory with the .EXE module, even though I had deleted the old .RC file from my project and added the new .RC file. I renamed the .RES file to match the name of the new .RC file I am using. I still do not understand what was happening there. I must admit that I am still a little confused as to exactly how many of resource.h, whatever.RC, whatever.RES etc must be explicitly added to a project in order to get everything joining up properly. I am especially confused now about what to do if, as I found, I have to rename one of them. Also, at the start of a project, where does the first resource.H come from?

regards, Tony Richards

Hi Tony,

> I must admit that I am still a little confused as to exactly how many of resource.h, whatever.RC, whatever.RES etc must be explicitly added to a project in order to get everything joining up properly. I am especially confused now about what to do if, as I found, I have to rename one of them. Also, at the start of a project, where does the first resource.H come from?

Developer Studio handling of resource files is a bit strange... You should not add the .RES file to your project. The .RES file is the output of the Resource Compiler - see Project -> Settings -> Resources tab for where the name of the .RES file is specified.

Concerning the initial Resource.h file, if you use a Fortran AppWizard that creates a .RC file, then it will also create Resource.h. If not, when you add your first resource to your project, both the .RC file and Resource.h will be created. It is the Developer Studio "Resource Editor" that writes the Resource.h and Resource.fd files. As you have seen, it sometimes gets confused and starts assigning duplicate IDs. I don't know what causes that.

Leo

Thanks Leo. Questions remain: why does Developer studio always produce an include file with the same name RESOURCE.H for all projects?
The RESOURCE.FD file can be renamed as it is only used in the FORTRAN code, but RESOURCE.H appears to be ALWAYS required by DevStudio when handling the resources for ANY project. I fear that the name RESOURCE.H is embedded in several places that the developer cannot reach.

This gets confusing when one has many projects. Can you enlighten me?

I don't know why MS chose RESOURCE.H for the name, rather than "project-name".h. You can change the name in the following way.

With the Resource View active, select View -> Resource Includes. You can change the name of the RESOURCE.H file in the "Symbol header file" edit field. Dev Studio will then use the same name, with the .FD extension, for the Fortran include file.

Note that there is also a View -> Resource Symbols menu item. You can change the values of your resource IDs from there, but it is somewhat tedious...

Leo

Leave a Comment

Please sign in to add a comment. Not a member? Join today