Use of DLGINCLUDE in Resource Files

Last reviewed: November 2, 1995
Article ID: Q91697
The information in this article applies to:
  • Microsoft Win32 Software Development Kit (SDK) versions 3.1, 3.5, 3.51, and 4.0

SUMMARY

The dialog editor needs a way to know what include file is associated with a resource file that it opens. Rather than prompt the user for the name of the include file, the name of the include file is embedded in the resource file in most cases.

MORE INFORMATION

Embedding the name of the include file is done with a resource of type RCDATA with the special name DLGINCLUDE. This resource is placed into the .RES file and contains the name of the include file. The dialog editor looks for this resource when it loads a .RES file. If this resource is found, then the include file is opened also; if not, the editor prompts the user for the name of the include file.

In some Windows 3.1 build environments, the dialog editor was used to create dialogs that were placed in more than one .DLG file. These different .DLG files were then included in one .RC file, which was compiled with the resource compiler. Therefore, the resource file gets multiple copies of a RCDATA type resource with the same name, DLGINCLUDE, but the resource compiler and dialog editor don't complain.

In the Win32 SDK, changes were made so that this resource has its own resource type; it was changed from an RCDATA-type resource with the special name, DLGINCLUDE, to a DLGINCLUDE resource type whose name can be specified. The dialog editor would look for resources of the type DLGINCLUDE.

We are being more strict about the need for resources to be unique in the Win32 SDK than the Windows 3.1 SDK. This is good because there was never any guarantee at run time as to which of the two or more resources would be returned by LoadResource().

This means that some applications being ported to Windows NT give an error when their resources are compiled because they have duplicate RCDATA type resources with the same name (DLGINCLUDE). This error is by design. The workaround is straightforward: delete all the DLGINCLUDE RCDATA type resource statements from all the .DLG files.

Finally, because it does not make sense to have the DLGINCLUDE type resources in the executable, the linker will strip them out so that they don't get linked into the EXE.


Additional reference words: 3.10 3.50 4.00 95
KBCategory: kbtool
KBSubcategory: TlsDlg


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: November 2, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.