ResOrg Benefits and Features
For each project within a solution, ResOrg allows the symbol definition file (it doesn't have to be called resource.h, incidentally) for one or more projects to be viewed or edited directly.
If (as happens all too often) a symbol file has two or more symbols with the same value, they will be identified as conflicting symbols and displayed in red:
As you might expect, individual symbols can be added, edited or removed (be careful with the latter!), but the real power of ResOrg is its ability to detect conflicts or out of range symbols and intelligently renumber them.
The Symbol Properties Dialog for a symbol whose value conflicts with another in the same resource symbol file will warn of the conflict, and provide a quick way to resolve it:
Visual Studio Ribbon Resources
The resource editor in Visual Studio 2010 onwards includes a Ribbon Designer which needs to be taken into account when renumbering symbols. The Designer stores details of the symbols used in a ribbon control in an XML based .mfcribbon-ms file, and as this information includes symbol values these files may also need to updated when the corresponding resource symbol file is edited.
Fortunately, ResOrg 2.0 can do this - if the value of a symbol which appears in a .mfcribbon-ms file associated with the same .rc file is changed, ResOrg will now automatically update the contents of the .mfcribbon-ms file when the symbol file is saved:
The symbol highlighted in yellow above is an example - if the value of IDB_BUTTONS is changed in the left hand pane and the file saved, the corresponding value in the ribbon.mfcribbon-ms file will be updated automatically. As the ribbon.mfcribbon-ms file is open in the IDE in this case the IDE then prompts to reload it.
In large projects the ability to identify problems can become critical. To that end, ResOrg provides facilities for generating HTML reports showing the symbols in a module - or just those which ResOrg has identified have a problem with their name or value:
Although the two reports provided (a full Symbols Report and a Problem Symbols Report) should meet most needs it is also possible to use an external XSLT stylesheet to produce custom reports. Riverblade would of course be pleased to assist customers with specific requirements in this area. Please do not hesitate to contact us if this is the case.
Symbol Renumbering Wizard
If bulk changes are required, the Resource Symbol Renumbering Wizard will guide you through the process of renumbering all of the symbols in a given resource file (click on any thumbnail to see a larger image):
When run, the wizard will identify suitable ranges for the symbols, and renumber them appropriately. Conflicting symbol values can be quickly and easily eliminated by this process.
Exclusion of symbols from renumbering operations
Unfortunately, renumbering some symbols can cause problems. Although the Symbol Renumbering Wizard allows individual symbols to be excluded from renumbering operations, it can be convenient to globally exclude specific symbols (such as IDR_MAINFRAME) from automatic renumbering across any file.
The "Fixed Symbols" page in the Options Dialog provides the ability to do this:
Any symbols listed in this page will not be automatically considered for renumbering by the Symbol Renumbering Wizard.
A Note of Caution
Please exercise caution when renumbering symbols using ResOrg. Under certain circumstances doing so can cause problems, which is the last thing we want to happen.
The main issues we are aware of are:
- If you have a dialog template which contains a bitmap resource, the Visual C++ Resource Editor stores the ID of the bitmap as a literal value, rather than an ID. Changing the value of the bitmap's ID will break this association, and you will have to re-enter the ID in the dialog editor or the bitmap will not be displayed.
- The icon shown by the Windows shell for an application is that with the lowest ID. If you renumber the icons this may no longer be the case, and the wrong icon may be shown.
- Visual C++ will not automatically rebuild implementation files as a result of resource symbol changes, since doing so would cause all dependent files (and there could be a lot of them) to be rebuilt every time a resource symbol was added or changed.
Unfortunately, when you renumber symbols this is exactly what you want to happen - if you don't rebuild the right files, all sorts of strange behaviour can result! If in doubt, clean the affected projects before attempting to rebuild them.
MFC Technical Note TN035: Using Multiple Resource Files and Header Files with Visual C++ discusses this subject.
Since ResOrg allows you to specify which symbols you want to renumber (and how to do it), you can exclude symbols which are likely to cause problems if their values are changed from the renumbering process.
A good version control system is invaluable here, since it provides a quick way to review (and throw away if necessary) any changes made. If you haven't got access to one, please back up your resource and resource symbol files before attempting to renumber symbols.
Ultimately, we aim to add the capability to read/write resource files directly. Once this is in place, ResOrg will be able to circumvent some of these issues.