Partager via


TN035 : Utilisation de plusieurs fichiers de ressources et fichiers d’en-tête avec Visual C++

Remarque

La note technique suivante n’a pas été mise à jour depuis sa première inclusion dans la documentation en ligne. Par conséquent, certaines procédures et rubriques peuvent être obsolètes ou incorrectes. Pour obtenir les informations les plus récentes, il est recommandé de rechercher la rubrique intéressante dans l’index de documentation en ligne.

Cette remarque décrit comment l’éditeur de ressources Visual C++ prend en charge plusieurs fichiers de ressources et fichiers d’en-tête partagés dans un projet unique ou partagés entre plusieurs projets et comment vous pouvez tirer parti de cette prise en charge. Cette note répond à ces questions :

  • Quand vous souhaiterez peut-être fractionner un projet en plusieurs fichiers de ressources et/ou fichiers d’en-tête, et comment procéder

  • Comment partager un fichier d’en-tête .H commun entre deux .RC fichiers

  • Comment diviser les ressources de projet en plusieurs .RC fichiers

  • Comment vous (et les outils) gérez-vous les dépendances de build entre les fichiers .RC, .CPP et .H ?

Sachez que si vous ajoutez un fichier de ressources supplémentaire à votre projet, ClassWizard ne reconnaît pas les ressources dans le fichier ajouté.

Cette note est structurée pour répondre aux questions ci-dessus comme suit :

  • Vue d’ensemble de la façon dont Visual C++ gère les fichiers de ressources et les fichiers d’en-tête fournit une vue d’ensemble de la façon dont la commande Resource Set Include dans Visual C++ vous permet d’utiliser plusieurs fichiers de ressources et fichiers d’en-tête dans le même projet.

  • L’analyse des fichiers .RC et .H créés par AppWizard examine les fichiers de ressources et d’en-têtes multiples utilisés par une application créée avec AppWizard. Ces fichiers servent de modèle pour d’autres fichiers de ressources et fichiers d’en-tête que vous souhaiterez peut-être ajouter à votre projet.

  • L’inclusion de fichiers d’en-tête supplémentaires décrit l’emplacement où vous souhaiterez peut-être inclure plusieurs fichiers d’en-tête et fournit des détails sur la procédure à suivre.

  • Le partage d’un fichier d’en-tête entre deux .RC fichiers montre comment partager un fichier d’en-tête entre plusieurs .RC fichiers dans différents projets, ou peut-être dans le même projet.

  • L’utilisation de plusieurs fichiers de ressources dans le même projet décrit l’emplacement où vous souhaiterez peut-être diviser votre projet en plusieurs .RC fichiers et fournit des détails sur la procédure à suivre.

  • L’application des fichiers Visual C++ non modifiables décrit comment vous pouvez vous assurer que Visual C++ ne modifie pas et réforme involontairement une ressource personnalisée.

  • .RC décrit comment partager les mêmes symboles entre plusieurs fichiers et comment éviter l'attribution de valeurs ID numériques en double.

  • La gestion des dépendances entre .RC, .CPPet .H les fichiers décrit comment Visual C++ évite les fichiers de recompilation .CPP inutiles qui dépendent des fichiers de symboles de ressource.

  • La façon dont Visual C++ gère Set Include fournit des informations techniques sur la façon dont Visual C++ effectue le suivi de plusieurs fichiers (imbriqués) .RC et de plusieurs fichiers d’en-tête inclus par un .RC fichier.

Vue d’ensemble de la façon dont Visual C++ gère les fichiers de ressources et les fichiers d’en-tête

Visual C++ gère un fichier de ressources unique .RC et un fichier d’en-tête correspondant .H sous la forme d’une paire de fichiers étroitement couplée. Lorsque vous modifiez et enregistrez des ressources dans un .RC fichier, vous modifiez et enregistrez indirectement des symboles dans le fichier correspondant .H . Bien que vous puissiez ouvrir et modifier plusieurs .RC fichiers à la fois (à l’aide de l’interface utilisateur MDI de Visual C++), pour tout fichier donné .RC , vous modifiez indirectement un fichier d’en-tête correspondant.

Boîte de dialogue Include des ressources de la vue Ressource

Pour accéder à Éléments de ressource inclus, ouvrez l’affichage des ressources, faites un clic droit sur le fichier .RC, puis sélectionnez Éléments de ressource inclus.

Fichier d'en-tête de symbole

Par défaut, Visual C++ nomme toujours le fichier RESOURCE.Hd’en-tête correspondant, quel que soit le nom du fichier de ressources (par exemple). MYAPP.RC Le fichier d’en-tête de symbole : section de la boîte de dialogue Éléments de ressource dans Visual C++, vous permet de modifier le nom de ce fichier d’en-tête. Entrez un nouveau nom de fichier dans la zone d’édition de la section.

Remarque

les fichiers de ressources qui ne se trouvent pas dans le même répertoire que le fichier .RC doivent ajouter un chemin relatif avec une barre oblique inverse échappée « \ » pour être correctement lus.

Directives de symboles en lecture seule

Bien que Visual C++ modifie uniquement un fichier d’en-tête pour un fichier donné .RC , Visual C++ prend en charge les références aux symboles définis dans des fichiers d’en-tête en lecture seule supplémentaires. La section Read-Only Directives de symboles : dans la boîte de dialogue Ressources incluses vous permet de spécifier un nombre quelconque de fichiers d’en-tête en lecture seule supplémentaires en tant que directives de symboles Read-Only. La restriction « en lecture seule » signifie que lorsque vous ajoutez une nouvelle ressource dans le .RC fichier, vous pouvez utiliser un symbole défini dans le fichier d’en-tête en lecture seule. Toutefois, si vous supprimez la ressource, le symbole reste toujours défini dans le fichier d’en-tête en lecture seule. Vous ne pouvez pas modifier la valeur numérique affectée à un symbole en lecture seule.

Directives au moment de la compilation

Visual C++ prend également en charge l’imbrication de fichiers de ressources, où un .RC fichier est inclus dans un autre à l’aide d’une #include directive. Lorsque vous modifiez un fichier donné .RC à l’aide de Visual C++, toutes les ressources des fichiers inclus ne sont pas visibles. Toutefois, lorsque vous compilez le .RC fichier, les fichiers inclus sont également compilés. La section Compile-Time Directives : dans la boîte de dialogue Ressources Inclus vous permet de spécifier un nombre quelconque de .RC fichiers à inclure en tant que directives Compile-Time.

Notez ce qui se passe si vous lisez dans Visual C++ un .RC fichier qui inclut un autre .RC fichier qui n’est pas* spécifié en tant que directive Compile-Time. Cette situation peut survenir lorsque vous apportez à Visual C++ un .RC fichier que vous aviez précédemment maintenu manuellement avec un éditeur de texte. Lorsque Visual C++ lit le fichier inclus .RC , il fusionne les ressources incluses dans le fichier parent .RC . Lorsque vous enregistrez le fichier parent .RC , l’instruction #include , en vigueur, sera remplacée par les ressources incluses. Si vous ne souhaitez pas que cette fusion se produise, vous devez supprimer l’instruction #include du fichier parent .RCavant de la lire dans Visual C++, puis en utilisant Visual C++, ajoutez la même #include instruction qu’une directive Compile-Time.

Visual C++ enregistre dans un fichier .RC les trois types d'informations ci-dessus (Fichier d'en-tête de symbole, Directives de symboles en lecture seule et Directives au moment de la compilation) dans les directives #includeet dans les ressources TEXTINCLUDE. Les ressources TEXTINCLUDE, un détail d’implémentation que vous n'avez normalement pas besoin de traiter, sont expliquées dans Comment Visual C++ gère l'ensemble des informations incluses.

Analyse des fichiers .RC et .H créés par AppWizard

L’examen du code d’application produit par AppWizard fournit des informations sur la façon dont Visual C++ gère plusieurs fichiers de ressources et fichiers d’en-tête. Les extraits de code examinés ci-dessous proviennent d’une MYAPP application produite par AppWizard à l’aide des options par défaut.

Une application créée par AppWizard utilise plusieurs fichiers de ressources et plusieurs fichiers d’en-tête, comme résumé dans le diagramme ci-dessous :

   RESOURCE.H     AFXRES.H
          \       /
           \     /
          MYAPP.RC
              |
              |
        RES\MYAPP.RC2
        AFXRES.RC
        AFXPRINT.RC

Vous pouvez afficher ces relations multiples de fichiers à l’aide de la commande Fichier/Set Includes de Visual C++.

MYAPP.RC
Fichier de ressources d’application que vous modifiez à l’aide de Visual C++.

RESOURCE.H est le fichier d’en-tête spécifique à l’application. Elle est toujours nommée RESOURCE.H par AppWizard, en accord avec la dénomination par défaut du fichier d'en-tête de Visual C++. La propriété #include de ce fichier d'en-tête est la première instruction dans le fichier de ressources (MYAPP.RC) :

//Microsoft Visual C++ generated resource script
//
#include "resource.h"

RES\MYAPP.RC2
Contient des ressources qui ne seront pas modifiées par Visual C++, mais qui seront incluses dans le fichier compilé .EXE final. AppWizard ne crée aucune ressource de ce type par défaut, car Visual C++ peut modifier toutes les ressources standard, y compris la ressource de version (une nouvelle fonctionnalité dans cette version). Un fichier vide est généré par AppWizard au cas où vous souhaitez ajouter vos propres ressources mises en forme personnalisées à ce fichier.

Si vous utilisez des ressources mises en forme personnalisées, vous pouvez les ajouter et les modifier à RES\MYAPP.RC2 l’aide de l’éditeur de texte Visual C++.

AFXRES.RC et AFXPRINT.RC contiennent des ressources standard requises par certaines fonctionnalités de l’infrastructure. Comme RES\MYAPP.RC2, ces deux fichiers de ressources fournis par l’infrastructure sont inclus à la fin de MYAPP.RC, et ils sont spécifiés dans la boîte de dialogue "Directives Compile-Time" des paramètres d'inclusion. Par conséquent, vous n’affichez pas ou modifiez directement ces ressources d’infrastructure pendant que vous modifiez MYAPP.RC dans Visual C++, mais elles sont compilées dans le fichier binaire .RES de l’application et le fichier final .EXE . Pour plus d’informations sur les ressources de framework standard, notamment sur les procédures de modification de ces ressources, consultez la note technique 23.

AFXRES.H définit des symboles standard, tels que ID_FILE_NEW, utilisés par l’infrastructure et spécifiquement utilisés dans AFXRES.RC. AFXRES.H utilise également #include pour inclure WINRES.H, qui contient un sous-ensemble de WINDOWS.H nécessaire pour les fichiers .RC générés par Visual C++ et AFXRES.RC. Les symboles définis dans AFXRES.H sont disponibles lorsque vous modifiez le fichier de ressources de l’application (MYAPP.RC). Par exemple, ID_FILE_NEW est utilisé pour l’élément de menu FileNew dans la ressource de menu du fichier MYAPP.RC. Vous ne pouvez pas modifier ou supprimer ces symboles définis par l’infrastructure.

Inclusion de fichiers d’en-tête supplémentaires

L’application créée par AppWizard inclut uniquement deux fichiers d’en-tête : RESOURCE.H et AFXRES.H. Seul RESOURCE.H est spécifique à l'application. Vous devrez peut-être inclure des fichiers d’en-tête en lecture seule supplémentaires dans les cas suivants :

Le fichier d’en-tête est fourni par une source externe ou vous souhaitez partager le fichier d’en-tête entre plusieurs projets ou plusieurs parties du même projet.

Le fichier d’en-tête a une mise en forme et des commentaires que vous ne souhaitez pas que Visual C++ modifie ou filtre lorsqu’il enregistre le fichier. Par exemple, vous souhaitez peut-être conserver #define qui utilise une arithmétique symbolique tel que :

#define RED 0
#define BLUE 1
#define GREEN 2
#define ID_COLOR_BUTTON 1001
#define ID_RED_BUTTON (ID_COLOR_BUTTON + RED)
#define ID_BLUE_BUTTON (ID_COLOR_BUTTON + BLUE)
#define ID_GREEN_BUTTON (ID_COLOR_BUTTON + GREEN)

Vous pouvez inclure des fichiers d’en-tête en lecture seule supplémentaires à l’aide de la commande Resource Include pour spécifier l’instruction #include en tant que deuxième directive de symbole Read-Only, comme dans :

#include "afxres.h"
#include "second.h"

Le nouveau diagramme de relation de fichier ressemble maintenant à ceci :

                   AFXRES.H
    RESOURCE.H     SECOND.H
          \       /
           \     /
          MYAPP.RC
              |
              |
        RES\MYAPP.RC2  
        AFXRES.RC
        AFXPRINT.RC

Partage d’un fichier d’en-tête entre deux .RC fichiers

Vous pouvez partager un fichier d’en-tête entre deux .RC fichiers qui se trouvent dans des projets différents, ou éventuellement le même projet. Pour ce faire, appliquez la technique Read-Only Directives décrite ci-dessus aux deux .RC fichiers. Dans le cas où les deux .RC fichiers concernent des applications différentes (projets différents), le résultat est illustré dans le diagramme suivant :

     RESOURCE.H   AFXRES.H   RESOURCE.H  
    (for MYAPP1)  SECOND.H   (for MYAPP2)
          \       /     \       /
           \     /       \     /
          MYAPP1.RC      MYAPP2.RC
           /    \        /     \
          /      \      /       \
RES\MYAPP1.RC2  AFXRES.RC     RES\MYAPP2.RC2
                AFXPRINT.RC

Le cas où le deuxième fichier d’en-tête est partagé par deux .RC fichiers dans la même application (projet) est décrit ci-dessous.

Utilisation de plusieurs fichiers de ressources dans le même projet

Visual C++ et le compilateur de ressources prennent en charge plusieurs fichiers .RC dans le même projet via des directives #include qui incluent un fichier .RC dans un autre. L'imbrication multiple est autorisée. Il existe différentes raisons de fractionner les ressources de votre projet en plusieurs .RC fichiers :

  • Il est plus facile de gérer un grand nombre de ressources parmi plusieurs membres de l’équipe de projet si vous fractionnez les ressources en plusieurs .RC fichiers. Si vous utilisez un package de gestion du contrôle de code source pour extraire des fichiers et archiver les modifications, le fractionnement des ressources en plusieurs .RC fichiers vous permet de contrôler plus finement la gestion des modifications apportées aux ressources.

  • Si vous souhaitez utiliser des directives de préprocesseur, telles que #ifdef, #endif et #define, pour certaines parties de vos ressources, vous devez les isoler dans des ressources en lecture seule qui seront compilées par le Resource Compiler.

  • Les fichiers de composant .RC chargent et enregistrent plus rapidement dans Visual C++ qu’un seul fichier composite .RC .

  • Si vous souhaitez conserver une ressource avec un éditeur de texte dans un formulaire lisible par l’homme, vous devez le conserver dans un .RC fichier distinct de celui qui modifie Visual C++.

  • Si vous devez conserver une ressource définie par l’utilisateur dans un formulaire binaire ou texte interprétable par un autre éditeur de données spécialisé, vous devez le conserver dans un fichier distinct .RC afin que Visual C++ ne modifie pas le format en données hexadécimales. Les .WAV ressources de fichier (son) dans l’exemple MFC Advanced Concepts SPEAKN sont un bon exemple.

Vous pouvez inclure SECOND.RC dans les Directives Compile-Time de la boîte de dialogue "Définir les inclusions" :

#include "res\myapp.rc2"  // non-Visual C++ edited resources
#include "second.rc"  // THE SECOND .RC FILE

#include "afxres.rc"  // Standard components
#include "afxprint.rc"  // printing/print preview resources

Le résultat est illustré dans le diagramme suivant :

   RESOURCE.H     AFXRES.H
          \       /
           \     /
          MYAPP.RC
              |
              |
        RES\MYAPP.RC2
        SECOND.RC  
        AFXRES.RC
        AFXPRINT.RC

À l’aide de directives au moment de la compilation, vous pouvez organiser vos ressources modifiables et non modifiables dans Visual C++ en plusieurs fichiers .RC, où le fichier principal MYAPP.RC ne fait rien d’autre qu'un #include des autres fichiers .RC. Si vous utilisez un fichier projet .MAK Visual Studio C++, vous devez inclure le fichier principal .RC dans le projet afin que toutes les ressources incluses soient compilées avec votre application.

Application des fichiers Visual C++ non modifiables

Le fichier créé par AppWizard, RES\MYAPP.RC2, est un exemple de fichier contenant des ressources que vous ne souhaitez pas l'importer accidentellement dans Visual C++ et ensuite le sauvegarder en perdant des informations de mise en forme. Pour vous protéger contre ce problème, placez les lignes suivantes au début du RES\MYAPP.RC2 fichier :

#ifdef APSTUDIO_INVOKED
    #error this file is not editable by Visual C++
#endif //APSTUDIO_INVOKED

Lorsque Visual C++ compile le fichier .RC, il définit à la fois APSTUDIO_INVOKED et RC_INVOKED. Si la structure de fichiers créée par AppWizard est endommagée et visual C++ lit la ligne #error ci-dessus, elle signale une erreur irrécupérable et abandonne la lecture du .RC fichier.

Gestion des symboles partagés par plusieurs fichiers Visual C++ modifiés .RC

Deux problèmes se produisent lorsque vous fractionnez vos ressources en plusieurs .RC fichiers que vous souhaitez modifier séparément dans Visual C++ :

  • Vous pouvez partager les mêmes symboles sur plusieurs .RC fichiers.

  • Vous devez aider Visual C++ à éviter d’affecter les mêmes valeurs numériques d’ID aux ressources distinctes (symboles).

Le diagramme suivant illustre une organisation des fichiers .RC et .H qui traite du premier problème :

              MYAPP.RC
             /         \
            /           \
MYSTRS.H   / MYSHARED.H  \  MYMENUS.H
     \    /    /      \   \    \
      \  /    /        \   \    \
      MYSTRS.RC         MYMENUS.RC

Dans cet exemple, les ressources de chaîne sont conservées dans un fichier de ressources, MYSTRS.RCet les menus sont conservés dans un autre. MYMENUS.RC Certains symboles, tels que les commandes, peuvent avoir besoin d’être partagés entre les deux fichiers. Par exemple, un ID_TOOLS_SPELL peut être l'ID de commande de menu pour l'élément Spell dans un menu Outils ; il peut également être l'ID de chaîne de l'invite de commande affichée par le cadre dans la barre d'état de la fenêtre principale de l'application.

Le ID_TOOLS_SPELL symbole est conservé dans le fichier d’en-tête partagé. MYSHARED.H Vous gérez manuellement ce fichier d’en-tête partagé avec un éditeur de texte ; Visual C++ ne le modifie pas directement. Dans les deux fichiers MYSTRS.RC de ressources et MYMENUS.RC, vous spécifiez #include "MYSHARED.H" dans les directives Read-Only pour MYAPP.RC, à l’aide de la commande Resource Include , comme décrit précédemment.

Il est plus pratique d’anticiper un symbole que vous partagerez avant de tenter de l’utiliser pour identifier n’importe quelle ressource. Ajoutez le symbole au fichier d’en-tête partagé et, si vous n’avez pas déjà inclus le fichier d’en-tête partagé dans les directives Read-Only pour le .RC fichier, faites-le avant d’utiliser le symbole. Si vous n’avez pas prévu de partager le symbole de cette façon, vous devrez déplacer manuellement (à l’aide d’un éditeur de texte) l’instruction #define pour le symbole de MYMENUS.H vers MYSHARED.H avant de l'utiliser dans MYSTRS.RC.

Lorsque vous gérez des symboles dans plusieurs .RC fichiers, vous devez également aider Visual C++ à éviter d’affecter les mêmes valeurs numériques d’ID aux ressources distinctes (symboles). Pour un fichier donné .RC , Visual C++ affecte de façon incrémentielle des ID dans chacun des quatre domaines d’ID. Entre les sessions d’édition, Visual C++ effectue le suivi du dernier ID qu’il a affecté dans chacun des domaines du fichier d’en-tête de symbole pour le .RC fichier. Voici les APS_NEXT valeurs d’un fichier (nouveau) .RC vide :

#define _APS_NEXT_RESOURCE_VALUE  101
#define _APS_NEXT_COMMAND_VALUE   40001
#define _APS_NEXT_CONTROL_VALUE   1000
#define _APS_NEXT_SYMED_VALUE     101

_APS_NEXT_RESOURCE_VALUE est la valeur de symbole suivante qui sera utilisée pour une ressource de dialogue, une ressource de menu, et ainsi de suite. La plage valide pour les valeurs de symboles de ressource est de 1 à 0x6FFF.

_APS_NEXT_COMMAND_VALUE est la valeur de symbole suivante qui sera utilisée pour une identification de commande. La plage valide pour les valeurs de symboles de commande est 0x8000 à 0xDFFF.

_APS_NEXT_CONTROL_VALUE est la valeur de symbole suivante qui sera utilisée pour un contrôle de boîte de dialogue. La plage valide pour les valeurs des symboles de contrôle de boîte de dialogue est de 8 à 0xDFFF.

_APS_NEXT_SYMED_VALUE est la valeur de symbole suivante qui sera émise lorsque vous affectez manuellement une valeur de symbole à l’aide de la commande New dans l’Explorateur de symboles.

Visual C++ commence par des valeurs légèrement plus élevées que la valeur juridique la plus faible lors de la création d’un .RC fichier. AppWizard initialise également ces valeurs à quelque chose de plus approprié pour les applications MFC. Pour plus d’informations sur les plages de valeurs d’ID, consultez La note technique 20.

À présent, chaque fois que vous créez un fichier de ressources, même dans le même projet, Visual C++ définit les mêmes _APS_NEXT_ valeurs. Cela signifie que si vous ajoutez, par exemple, plusieurs dialogues dans deux fichiers différents .RC , il est très probable que la même valeur #define soit affectée à différents dialogues. Par exemple, IDD_MY_DLG1 dans le premier .RC fichier peut être affecté le même nombre, 101, que IDD_MY_DLG2 dans un deuxième .RC fichier.

Pour éviter ce problème, vous devez réserver une plage numérique distincte pour chacun des quatre domaines d’ID dans les fichiers respectifs .RC . Définissez les plages en mettant à jour manuellement les _APS_NEXT valeurs dans chacun des .RC fichiers avant de commencer à ajouter des ressources. Par exemple, si le premier .RC fichier utilise les valeurs par défaut _APS_NEXT , vous pouvez affecter les valeurs suivantes _APS_NEXT au deuxième .RC fichier :

#define _APS_NEXT_RESOURCE_VALUE  2000
#define _APS_NEXT_COMMAND_VALUE   42000
#define _APS_NEXT_CONTROL_VALUE   2000
#define _APS_NEXT_SYMED_VALUE     2000

Bien sûr, il est toujours possible que Visual C++ affecte autant d’ID dans le premier .RC fichier que les valeurs numériques commencent à chevaucher celles réservées pour le deuxième .RC fichier. Vous devez réserver des plages suffisamment étendues afin que cette collision ne se produise pas.

Gestion des dépendances entre les fichiers .RC, .CPP et .H

Lorsque Visual C++ enregistre un .RC fichier, il enregistre également les modifications de symboles dans le fichier correspondant RESOURCE.H . Tous vos fichiers .CPP qui font référence aux ressources du fichier .RC doivent utiliser #include pour inclure le fichier RESOURCE.H, généralement à partir du fichier d'en-tête principal de votre projet. Cette inclusion entraîne un effet secondaire indésirable en raison de la gestion interne de projet de l’environnement de développement, qui analyse les fichiers sources pour les dépendances d’en-tête. Chaque fois que vous ajoutez un nouveau symbole dans Visual C++, tous les .CPP fichiers qui ont #include "RESOURCE.H" des directives doivent être recompilés.

Visual C++, contourne la dépendance par RESOURCE.H en incluant le commentaire suivant comme première ligne dans le fichier RESOURCE.H :

//{{NO_DEPENDENCIES}}

L’environnement de développement interprète ce commentaire en ignorant les modifications apportées à RESOURCE.H afin que les fichiers dépendants .CPP n’aient pas besoin d’être recompilés.

Visual C++ ajoute toujours la ligne de //{{NO_DEPENDENCIES}} commentaire à un .RC fichier lorsqu’il enregistre le fichier. Dans certains cas, le contournement de la dépendance RESOURCE.H de build peut entraîner des erreurs d’exécution non détectées au moment du lien. Par exemple, si vous utilisez l’Explorateur de symboles pour modifier la valeur numérique affectée à un symbole pour une ressource, la ressource n’est pas correctement trouvée et chargée au moment de l’exécution de l’application si le .CPP fichier faisant référence à la ressource n’est pas recompilé. Dans ce cas, vous devez recompiler explicitement tous .CPP les fichiers que vous savez sont affectés par les modifications de symboles dans RESOURCE.H ou sélectionner Reconstruire tout. Si vous avez besoin de modifier fréquemment des valeurs de symboles pour un certain groupe de ressources, vous trouverez probablement plus pratique et plus sûr de décomposer ces symboles dans un fichier d’en-tête en lecture seule distinct, comme décrit dans la section ci-dessus , y compris des fichiers d’en-tête supplémentaires.

Comment Visual C++ gère les informations Set Includes

Comme indiqué ci-dessus, la commande Set Include du menu Fichier vous permet de spécifier trois types d’informations :

  • Fichier d'en-tête de symbole

  • Directives de symboles en lecture seule

  • Directives au moment de la compilation

Le tableau suivant décrit comment Visual C++ gère ces informations dans un .RC fichier. Vous n’avez pas besoin de ces informations pour utiliser Visual C++, mais cela peut améliorer votre compréhension afin que vous puissiez utiliser plus en toute confiance la fonctionnalité Set Includes.

Chacun des trois types ci-dessus d’informations Set Include est stocké dans le .RC fichier sous deux formes : (1) comme #include ou d’autres directives interprétables par le compilateur de ressources, et (2) comme ressources spéciales TEXTINCLUDE interprétables uniquement par Visual C++.

L’objectif de la TEXTINCLUDE ressource est de stocker en toute sécurité les informations Set Include dans un formulaire facilement présentable dans la boîte de dialogue Set Include de Visual C++. TEXTINCLUDE est un type de ressource défini par Visual C++. Visual C++ reconnaît trois ressources spécifiques TEXTINCLUDE qui ont les numéros d’identification des ressources 1, 2 et 3 :

TEXTINCLUDE ID de ressource Type d’ensemble inclut des informations
1 Fichier d'en-tête de symbole
2 Directives de symboles en lecture seule
3 Directives au moment de la compilation

Chacun des trois types d'informations Set Includes est illustré par les fichiers MYAPP.RC et RESOURCE.H par défaut créés par AppWizard, comme décrit ci-dessous. Les jetons supplémentaires \0 et "" entre les blocs BEGIN et END sont requis par la syntaxe RC pour spécifier respectivement les chaînes terminées par un zéro et le caractère de guillemet double.

Fichier d'en-tête de symbole

La forme des informations de fichier d’en-tête de symbole interprétées par le compilateur de ressources est simplement une #include instruction :

#include "resource.h"

La ressource correspondante TEXTINCLUDE est la suivante :

1 TEXTINCLUDE DISCARDABLE
BEGIN
    "resource.h\0"
END

Directives de symboles en lecture seule

Read-Only Directives de symboles sont incluses en haut de MYAPP.RC dans la forme suivante, interprétées par le compilateur de ressources :

#include "afxres.h"

La ressource correspondante TEXTINCLUDE est la suivante :

2 TEXTINCLUDE DISCARDABLE
BEGIN
   "#include ""afxres.h""\r\n"
   "\0"
END

Directives au moment de la compilation

Les directives Compile-Time sont incluses à la fin de MYAPP.RC, dans la forme suivante interprétable par le compilateur de ressources :

#ifndef APSTUDIO_INVOKED
///////////////////////
//
// From TEXTINCLUDE 3
//
#include "res\myapp.rc2"  // non-Visual C++ edited resources

#include "afxres.rc"  // Standard components
#include "afxprint.rc"  // printing/print preview resources
#endif  // not APSTUDIO_INVOKED

La #ifndef APSTUDIO_INVOKED directive indique à Visual C++ d’ignorer les directives Compile-Time.

La ressource correspondante TEXTINCLUDE est la suivante :

3 TEXTINCLUDE DISCARDABLE
BEGIN
"#include ""res\myapp.rc2""  // non-Visual C++ edited resources\r\n"
"\r\n"
"#include ""afxres.rc""  // Standard components\r\n"
"#include ""afxprint.rc""  // printing/print preview resources\r\n"
"\0"
END

Voir aussi

Notes techniques par numéro
Notes techniques par catégorie