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

  • Article

Remarque

La note technique suivante n'a pas été mise à jour depuis son inclusion initiale 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 l'objet qui vous intéresse dans l'index de la 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 même projet ou parmi plusieurs projets, et comment 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 gérer (et les outils) les dépendances de génération entre .RC, .CPPet .H les fichiers

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 créés .RC par AppWizard et .H Fichiers examine les fichiers de ressources et d’en-têtes multiples utilisés par une application créée par AppWizard. Ces fichiers constituent un bon modèle pour les fichiers de ressources et les fichiers d'en-tête supplémentaires que vous pourriez souhaiter 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.

  • La gestion des symboles partagés par plusieurs fichiers modifiés .RC Visual C++décrit comment partager les mêmes symboles entre plusieurs .RC fichiers et comment éviter d’affecter des valeurs numériques d’ID 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 Éléments de ressource de l’affichage des ressources

Pour accéder à la ressource Inclut, ouvrez l’affichagedes ressources, puis cliquez avec le bouton droit sur le .RC fichier, 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 celui du .RC fichier doivent prédéfini un chemin relatif avec une séquence d’échappement- '\' pour être lus correctement.

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. Les directives de symbole en lecture seule : section de la boîte de dialogue Éléments de ressource vous permettent de spécifier un nombre quelconque de fichiers d’en-tête en lecture seule supplémentaires en tant que directives de symbole en lecture seule. 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 Directives de compilation au moment de la compilation : dans la boîte de dialogue Ressources Inclut , vous permet de spécifier un nombre quelconque de .RC fichiers à inclure en tant que directives de compilation.

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é comme directive au moment de la compilation. 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 .RC avant 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 .RC fichier les trois types de jeux ci-dessus Inclut des informations (fichier d’en-tête de symbole, directives de symbole en lecture seule et directives de compilation) dans #include les directives et dans les TEXTINCLUDE ressources. Les TEXTINCLUDE ressources, un détail d’implémentation que vous n’avez pas normalement besoin de traiter, sont expliquées dans la façon dont Visual C++ gère le jeu inclut des informations.

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

L'examen du code d'application produit par AppWizard permet d'en savoir plus sur la manière 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 le résume le diagramme ci-dessous :

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

Vous pouvez afficher ces multiples relations de fichiers à l'aide de la commande File/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, cohérente avec le nommage par défaut de Visual C++du fichier d’en-tête. Pour #include ce fichier d’en-tête, il s’agit de la première instruction du 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 pas ce genre de ressource par défaut, car Visual C++ peut modifier toutes les ressources standard, y compris la ressource de version (il s’agit d’une nouvelle fonctionnalité dans cette mise en production). Un fichier vide est généré par AppWizard au cas où vous souhaiteriez 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 , et ils sont spécifiés dans la boîte de MYAPP.RCdialogue Compiler-Time Directives of the Set Include. 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 #include également pour inclure WINRES.H, qui contient un sous-ensemble de WINDOWS.H ce qui est nécessaire par les fichiers générés .RC 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 il est utilisé pour l’élément FileNew de menu dans la MYAPP.RC ressource de menu du fichier. 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 l’application 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 des #define qui utilisent une arithmétique symbolique telle 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 en lecture seule, comme dans :

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

Le nouveau diagramme des relations de fichiers se présente désormais comme suit :

                   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 de directives en lecture seule 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 .RC fichiers dans le même projet via #include des directives qui incluent un fichier dans un .RC 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 case activée extraire des fichiers et case activée dans 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, #endifet , pour #definedes parties de vos ressources, vous devez les isoler dans des ressources en lecture seule qui seront compilées par le compilateur de ressources.

  • 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 de compilation dans la boîte de dialogue Définir inclut :

#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 ci-dessous :

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

À l’aide des directives de compilation, vous pouvez organiser vos ressources Visual C++modifiables et non modifiables dans plusieurs .RC fichiers, où le principal MYAPP.RC ne fait rien, mais #include les autres .RC fichiers. 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 RES\MYAPP.RC2 AppWizard est un exemple de fichier qui contient des ressources que vous ne souhaitez pas lire accidentellement dans Visual C++, puis écrire en arrière avec une perte d’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, il définit à la .RC 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 faire en sorte que Visual C++ évite d'assigner les mêmes valeurs numériques d'ID à des ressources distinctes (symboles).

Le diagramme suivant illustre une organisation de fichiers et .H d’organisations .RC 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, par exemple pour les commandes, peuvent devoir être partagés entre les deux fichiers. Par exemple, il ID_TOOLS_SPELL peut s’agir de l’ID de commande de menu de l’élément Spell dans un menu Outils ; et il peut également s’agir de l’ID de chaîne de l’invite de commandes affichée par l’infrastructure 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 en lecture seule 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 en lecture seule 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, par exemple, MYMENUS.H avant MYSHARED.H de l’utiliser.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 des valeurs de symboles de ressources est comprise entre 1 et 0x6FFF.

_APS_NEXT_COMMAND_VALUE est la valeur de symbole suivante qui sera utilisée pour une identification de commande. La plage valide des valeurs de symboles de commandes est comprise entre 0x8000 et 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 des valeurs de symboles de contrôles de boîtes de dialogue est comprise entre 8 et 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 fichiers avant de .RC 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 suffisamment de larges plages pour que cette collision ne se produise pas.

Gestion des dépendances entre .RCles fichiers et .H les .CPPfichiers

Lorsque Visual C++ enregistre un .RC fichier, il enregistre également les modifications de symboles dans le fichier correspondant RESOURCE.H . Tous vos .CPP fichiers qui font référence aux ressources du .RC fichier doivent être utilisés #include pour inclure le RESOURCE.H fichier, 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 en RESOURCE.H incluant le commentaire suivant comme première ligne du RESOURCE.H fichier :

//{{NO_DEPENDENCIES}}

L’environnement de développement interprète ce commentaire en ignorant les modifications apportées afin RESOURCE.H que les fichiers dépendants .CPP n’ont 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 Set Includes information

Comme décrit ci-dessus, la commande Set Includes 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'informations Set Includes
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 Include est illustré par défaut MYAPP.RC et RESOURCE.H les fichiers créés par AppWizard, comme décrit ci-dessous. Les jetons supplémentaires \0 et ""END les BEGIN blocs sont requis par la syntaxe RC pour spécifier respectivement les chaînes arrêtées 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

Les directives de symbole en lecture seule sont incluses en haut de la forme suivante, interprétables par le compilateur de MYAPP.RC 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 au moment de la compilation sont incluses à la fin de la forme suivante interprétable par le compilateur de MYAPP.RC 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 au moment de la compilation.

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