Texte de l’interface utilisateur et Aide pour Visual Studio

Texte et terminologie de l’interface utilisateur

Il est essentiel que le texte soit compréhensible pour que l’interface utilisateur soit efficace. Les utilisateurs de logiciels ont tendance à lire d’abord les étiquettes, à savoir celles qui sont les plus pertinentes pour effectuer la tâche en main. Le texte statique est lu avec moins de fréquence. Planifiez que les utilisateurs démarrent leurs sessions de travail avec une analyse rapide de l’ensemble de la fenêtre, suivie d’une lecture de l’interface utilisateur dans cet ordre approximatif :

1. Les contrôles interactifs au centre

2. Boutons de validation

3. Les autres emplacements des contrôles interactifs

4. Instructions principales

5. Explications supplémentaires

6. Window title

7. Autre texte statique dans le corps principal

Modèles d’utilisation pour le texte de l’interface utilisateur

Texte de la barre de titre

Le texte de la barre de titre doit correspondre à la commande qui a généré l’interface utilisateur.

Texte d’instruction (texte d’assistance)

Dans certains dialogues, il est utile de fournir des instructions principales pour expliquer ce qu’il faut faire dans la fenêtre ou dans la page. Il s’agit parfois de « texte d’assistance ».

Écriture de règles de style pour le texte d’assistance

• N’expliquez pas l’évidence. Sauf s’il est absolument nécessaire, n’incluez pas de texte d’instruction.

• Le texte d’instruction est toujours placé en haut de la boîte de dialogue et doit faire référence à la tâche en cours d’exécution.

• Expliquez précisément aux utilisateurs ce qu’ils doivent faire. Évitez une communication et une redondance excessives.

• Passez en revue chaque fenêtre et éliminez les mots et instructions dupliqués.

• Laissez le texte d’instruction court. Si des informations supplémentaires sont nécessaires pour certains utilisateurs ou scénarios, fournissez un lien vers une rubrique en ligne conceptuelle détaillée.

• Écrivez votre texte pour que chaque mot conserve du poids et soit nécessaire.

• Suivez les instructions Microsoft existantes pour le texte et le style et le ton de l’interface utilisateur.

Instructions complémentaires

Des instructions supplémentaires fournissent des informations supplémentaires qui aident l’utilisateur à comprendre les contrôles ou les regroupements de contrôles. Cela peut également inclure du texte d’indicateur nécessaire pour comprendre le format attendu par le contrôle d’entrée. Utilisez des instructions supplémentaires avec parcimonie. Réservez-les dans les cas où il est probable que l’utilisateur ne comprend pas pleinement les ramifications du choix qu’il effectue.

Texte supplémentaire dans Visual Studio

Texte supplémentaire dans Visual Studio

Informations Astuces

Souvent, le texte d’instruction peut être trop long pour positionner sur place dans l’interface utilisateur ou peut être utile uniquement pour les nouveaux utilisateurs, se sentant comme un encombrement pour les utilisateurs expérimentés. Dans ce cas, le texte d’instruction/d’information doit être placé en tant qu’info-bulle sous info-bulle.

Les informations Astuces doivent être placées près des contrôles auxquels ils sont liés et doivent utiliser l’icône info-bulle spécifique, ce qui n’est pas visible.

Exemple d’info-bulle dans Visual Studio

Écriture de règles de style pour Info Astuces

• Écrire des informations Astuces comme phrases complètes. Ils nécessitent des verbes spécifiques, une casse de phrase et une ponctuation de fin.

• Utilisez Info Astuces pour compléter vos principales instructions ou informations. Si vous utilisez simplement des mots différents pour reposer l’idée principale, vous n’avez pas besoin d’info-bulle.

• Gardez les infos Astuces courtes et douces. Utilisez de petits mots et une langue simple et quotidienne qui prend en charge et encourage l’utilisateur.

• Suivez les instructions Microsoft existantes pour le texte et le style et le ton de l’interface utilisateur.

Étiquettes de contrôle

Les étiquettes de contrôle doivent être courtes, concises et suivre les instructions du Bureau Windows pour les contrôles.

Pour plus d’informations sur le format et le positionnement des étiquettes de contrôle dans l’interface utilisateur, reportez-vous à Disposition pour Visual Studio.

Liens d’aide

Les liens d’aide peuvent être placés dans le texte d’instruction ou dans le corps de l’interface utilisateur. Il peut s’agir de liens vers l’aide ou de lancer des dialogues internes.

Règles de style visuel pour les liens d’aide

• Utilisez les couleurs d’environnement appropriées pour les liens hypertexte. Un lien hypertexte correctement mis en forme ne clignote pas brièvement en rouge lorsque vous cliquez dessus. Si vous voyez cela, il s’agit d’une indication que les couleurs de l’environnement ne sont pas utilisées.

• Les soulignements doivent être utilisés uniquement sur le pointage ou lorsque le lien est incorporé dans un paragraphe.

• Pour plus d’informations sur les styles visuels et d’interaction pour les liens hypertexte, consultez Boutons et liens hypertexte.

Écriture de règles de style pour les liens d’aide

• Lors du lancement de boîtes de dialogue, conservez les normes pour les points de suspension : aucun point de suspension pour la navigation, des points de suspension si la tâche nécessite une interface utilisateur supplémentaire.

  

  Un point de suspension (...) dans un lien d’aide indique que la tâche nécessite une interface utilisateur supplémentaire.

• Les liens ne doivent pas commencer par « Learn », car ce n’est pas l’intention de l’utilisateur. L’utilisateur souhaite répondre à une question spécifique, et ne reçoit pas d’éducation générale.

• Les liens d’aide à l’expression de sorte qu’ils posent la question que la rubrique répondra.

  Incorrect : « En savoir plus sur la tarification de Windows Azure Mobile Services »

  Correct : « Quelles options de tarification sont disponibles pour Windows Azure Mobile Services ? »

• N’utilisez jamais Click... pour le texte du lien.

• Ne liez jamais uniquement le mot « ici ». Cela pose problème pour certains lecteurs d’écran, qui n’expriment que le mot hypertexte.

  Incorrect : « Rechercher des informations sur Windows Azure Mobile Services ici »

  Correct : « Quelles options de tarification sont disponibles pour Windows Azure Mobile Services ? »

• Pour plus d’informations sur le style d’écriture correct pour les liens d’aide, consultez les conseils de Bureau Windows pour obtenir de l’aide.

Hint text

Le texte d’indicateur apparaît sous forme de filigrane dans un contrôle ou sous le contrôle. La mise en forme correcte sera appliquée à l’aide du jeton VSColors approprié. Environment.GrayText

Il peut apparaître dans un certain nombre de formulaires.

• À la place de l’étiquette de contrôle :

  

• Avec un verbe, en donnant des instructions :

  

• Avec du texte indiquant une entrée obligatoire :

  

Texte en filigrane

Sur une surface de conception vide, le texte doit indiquer ce qu’il faut faire, ainsi que fournir des liens pour ouvrir d’autres fenêtres associées, le cas échéant :

Exemple de texte en filigrane dans Visual Studio

Terminologie commune

Terme	Explication	Commentaire
Se connecter / Se déconnecter	Verbes utilisés synonymes du web pour représenter l’authentification dans une propriété web. Dans les clients, nous utilisons cette fois comme notion de niveau supérieur pour la connexion et l’expiration de la connexion utilisateur IDE, qui représente une identité de niveau supérieur qui fournit des fonctionnalités de niveau supérieur, telles que l’itinérance et les licences qui ne sont pas disponibles avec toutes les autres connexions.	L’utilisateur IDE est la seule fonctionnalité qui doit représenter un verbe de connexion/déconnexion, car il représente l’utilisateur IDE de niveau supérieur.
Connecter / Déconnexion	Utilisez des emplacements où une fonctionnalité conserve une connexion unique à un service en ligne.	L’Explorateur de serveurs, où vous ne pouvez avoir qu’une seule connexion Azure active à la fois, est un exemple de Connecter/Déconnexion.
Ajouter / Supprimer	Non destructeur. Utiliser lors de l’ajout ou de la suppression d’un élément d’une liste.	La boîte de dialogue de liste de serveurs tfS Connecter ion Manager est un exemple d’ajout/suppression.
Supprimer	Destructrice. Utilisez uniquement lorsque l’élément en cours de suppression sera définitivement dissocié carte ou supprimé du disque.	« Supprimer » nécessite généralement une invite si le résultat supprime un fichier du disque.

Messages d’erreur

Les erreurs arrivent. Définir des limitations sur ce que l’utilisateur peut faire est une première étape sensible pour empêcher les messages d’erreur évitables. Toutefois, lorsqu’une erreur se produit, un message d’erreur bien écrit peut aller beaucoup vers l’atténuation du problème. Les messages d’erreur sont sans doute l’un des types de notification les plus importants que l’utilisateur voit, car ils sont synchrones et indiquent un problème qui doit être résolu. Les messages d’erreur mal écrits permettent aux utilisateurs de décider de la cause des erreurs et des solutions possibles.

Les utilisateurs peuvent cesser de prêter attention aux messages d’erreur inutilisés ou déroutants. Par conséquent, écrivez uniquement les messages nécessaires qui ajoutent de la valeur à l’expérience utilisateur. Si le message est simplement une notification, utilisez une autre présentation.

Règles de création d’un message d’erreur

• Lors de la construction de messages d’erreur, choisissez le niveau d’erreur approprié pour l’audience. Visez des résumés simples qui fournissent une action que l’utilisateur peut entreprendre, le cas échéant. N’indiquez rien que l’utilisateur n’a pas besoin de savoir.

• Fournir une assistance constructive. Il est plus facile de lire et d’agir sur un message d’erreur qui contient des instructions.

• N’utilisez pas de doubles négatifs.

• Effectuez à la fois une grammaire automatisée et une grammaire manuelle et une case activée d’orthographe sur tout message d’erreur que vous écrivez.

• Pour les messages d’erreur complexes, évitez les communications séquentielles. N’utilisez jamais de raccordement F1 pour le message d’erreur. Le message lui-même doit être suffisant.

• Utilisez l’icône correcte.

• Facilitez la compréhension et l’utilisation des boutons qui ont des choix clairs, tels que « Supprimer » et « Annuler ».

• Pour les avertissements, soyez clair sur la conséquence de la procédure. Les boutons doivent indiquer la conséquence.

• Pour les erreurs, décrivez ce que l’utilisateur peut faire pour résoudre le problème. Les boutons doivent être des actions ou dire « Fermer ». N’utilisez pas de bouton « OK » pour un message d’erreur.

• Certaines questions à poser lors de la construction d’un message d’erreur :

  • L’utilisateur peut-il déterminer comment résoudre le problème avec cette erreur seule ?

  • L’utilisateur utilise-t-il le même vocabulaire que cette erreur ?

  • Cette erreur est-elle ambiguë ou partagée dans plusieurs situations ? Si c’est le cas, comment guider les utilisateurs vers la solution dont ils ont besoin ?

Erreurs de build

Étant donné que Visual Studio est un outil de développement logiciel, la plupart de ses composants ont une compilation, une conversion ou une étape d’encodage pour convertir le travail du développeur en formulaire binaire. Ces conversions peuvent entraîner des erreurs lorsque le compilateur ne peut pas traiter les fichiers créés de manière incorrecte ou lorsque les options du compilateur n’ont pas été définies correctement.

Les utilisateurs de Visual Studio peuvent passer un énorme nombre d’heures de développement pour résoudre les erreurs de génération. Ce temps de résolution augmente lorsque les erreurs ont des dépendances ou lorsque les messages d’erreur sont mal écrits, ce qui peut compliquer la découverte de la source de l’erreur.

Les meilleures erreurs de génération sont celles qui ne se produisent pas au premier endroit, c’est pourquoi Visual Studio fournit l’autocomplétion et les quiggles IntelliSense. Les validateurs de schéma et les outils similaires fournissent le même type de commentaires. Ces mécanismes guident de manière proactive l’utilisateur pour construire du code bien formé, ce qui réduit les risques d’erreurs de génération.

Visual Studio fournit une fenêtre d’outil dans laquelle les utilisateurs peuvent lire et parcourir les erreurs qui se sont produites dans leurs fenêtres de document. Les raccourcis clavier sont fournis afin que l’utilisateur puisse parcourir rapidement de grandes quantités de code et accéder directement à l’emplacement du problème. Visual Studio permet également à chaque erreur de génération d’être liée à un ID d’aide particulier mot clé/contexte afin que l’utilisateur puisse accéder directement à une rubrique d’aide qui fournit des informations plus détaillées sur l’erreur.

Écrivez des erreurs de build claires et concises :

• Utilisez un langage simple qui explique le problème avec peu ou pas de jargon du compilateur. Le texte d’une erreur de build ne doit pas être trop technique.

• Décrire les causes possibles. Par exemple, « Absence d’un signe deux-points entre la propriété et la valeur dans la déclaration « (propriété) : (valeur) ».

• Donnez des détails sur les correctifs potentiels. S’il n’y a pas suffisamment de place, des détails supplémentaires peuvent être placés dans la rubrique d’aide correspondante.

Composants d’un message d’erreur bien écrit

Utilisez le service de boîte de dialogue shell pour les messages d’erreur.

L’utilisation du service de boîte de dialogue shell vous permet de contrôler l’apparence du message, les polices en particulier, sans modifications majeures apportées à des éléments individuels. Utilisez les mécanismes IErrorInfo et signalez-les à l’aide d’IVsUIShell  ::SetErrorInfo/ReportErrorInfo.

Choisissez une présentation de notification efficace et appropriée.

Utilisez une boîte de dialogue modale avec un avertissement critique si une action immédiate est nécessaire pour éviter la perte de données (notification synchrone). Les icônes critiques sont réservées aux situations dans lesquelles fermer le message sans la lire peut entraîner des conséquences négatives. La perte de données est une situation critique qui nécessite une réponse au niveau de l’alarme. L’utilisation excessive de l’icône critique désensitise les utilisateurs à son importance. Si le message d’erreur est de nature informationnelle, envisagez d’utiliser des alternatives à une boîte de dialogue modale (notification asynchrone).

Fournissez une propre explication succincte de la raison pour laquelle le problème s’est produit plutôt qu’une explication technique.

Le surchargé des utilisateurs avec des détails techniques dans l’explication les rend plus susceptibles d’ignorer les messages d’erreur. Exemples de bonnes messages :

• « Impossible d’ouvrir le fichier demandé ».

• « Impossible de se connecter à Internet . »

Fournissez des informations sur la façon de résoudre le problème.

Proposez aux utilisateurs des suggestions de résolution du problème. Soyez honnête avec l’utilisateur s’il n’y a aucune suggestion. Fournissez des liens directs vers d’autres sources en ligne, telles que le support technique ou le support communautaire. Essayez de pointer les utilisateurs vers des informations en ligne spécifiques relatives au problème. Pour obtenir un ID d’erreur, envisagez de lier des utilisateurs à un thread de discussion sur cette erreur spécifique. Exemples de bonnes messages :

• « Assurez-vous que vous êtes connecté à Internet et réessayez cette opération. »

• « Assurez-vous que le fichier existe et que vous êtes autorisé à l’ouvrir. »

Écrivez un message court et au point.

Un message d’erreur peut notifier, expliquer et proposer une solution, mais il est toujours ignoré s’il est trop wordy. Une solution consiste à utiliser la divulgation progressive avec un bouton détails. Par exemple, donnez une brève description/solution, puis placez plus de détails sous un bouton Détails. Si les utilisateurs choisissent de lire plus d’informations sur l’erreur, ils peuvent le faire.

La langue du message doit être :

• Domaine approprié. Utilisez la langue que l’utilisateur comprend. Même si nos clients sont des développeurs, ils n’ont souvent pas le contexte et la terminologie que nous avons.

• Spécifique. Évitez les formulations vagues et donnez des noms et des emplacements spécifiques des objets impliqués. Par exemple, un message d’erreur tel que « caractère n’est pas valide » n’est pas utile. Quel caractère ? « Fichier introuvable ». Quel fichier ?

• Courtois. Ne blâmez pas l’utilisateur ou faites-lui sentir stupide. Évitez la langue hostile ou offensive (tuer, exécuter, mettre fin, fatal, illégal). Évitez le texte en majuscules, qui est souvent considéré comme criant et n’est pas aussi lisible. N’utilisez pas l’humour.

• Réponse correcte. Utilisez l’orthographe et la grammaire correctes (même en alphas). Les fautes de frappe ne sont pas professionnelles et embarrassantes.

• Approprié dans le contexte. Utilisez le texte du bouton approprié. Évitez le bouton « OK » et utilisez plutôt « Continuer » ou « Oui/Non ».

Exemples de messages d’erreur

Convenable	Incorrect
« Le numéro que vous avez composé n’est plus en service. Veuillez case activée le numéro et composer à nouveau ou composer 0 pour l’opérateur. »	- « Erreur (449) : Nombre illégal » - « Cette erreur d’exception non gérée indique que l’opération s’est terminée correctement. »

Accès à l’aide

En plus de la documentation dans MSDN, un utilisateur Visual Studio dispose de plusieurs points d’accès pour aider l’utilisateur dans l’interface utilisateur. Pour vous assurer que ces points d’accès sont constamment disponibles, les équipes de fonctionnalités doivent tirer parti du système d’aide proposé par l’environnement. Ces points d’accès sont les suivants :

• Texte d’instruction et supplémentaire dans les boîtes de dialogue. Texte statique qui donne un sens ou une explication, soit sur l’aire de l’interface utilisateur, soit disponible sur une icône info-bulle.

• Aide F1 (éditeur uniquement). Dans l’éditeur Visual Studio, un utilisateur peut faire confiance à tout moment, en appuyant sur F1 pour afficher une rubrique d’aide spécifique à la sélection actuelle. Vérifiez que les rubriques associées à F1 sont appropriées et informatives.

• Liens hypertexte vers les rubriques d’aide. Lien hypertexte dans une boîte de dialogue, une fenêtre outil ou une surface de conception qui lance une rubrique pour aider l’utilisateur à en savoir plus sur une technologie, une fonctionnalité ou des informations sur la façon d’accomplir une tâche.

• Mécanismes d’interface utilisateur d’assistance, tels que les balises actives et les dialogues de création. Ces mécanismes aident l’utilisateur à comprendre un élément d’interface utilisateur ou à faciliter une tâche, comme les balises actives ou les dialogues du générateur.

• Boutons d’aide de l’interface utilisateur (déconseillés). Indicateur visible dans la barre de titre qui donne accès à la rubrique d’aide F1 associée.

Détails

Texte d’instruction et supplémentaire dans les boîtes de dialogue

Dans les dialogues qui prennent en charge des tâches complexes, il peut être nécessaire de donner du texte d’instruction dans l’interface utilisateur, souvent en haut du dialogue ou près de contrôles complexes. Consultez le texte et la terminologie de l’interface utilisateur pour plus d’informations sur l’écriture de style.

Informations Astuces

Souvent, le texte d’instruction peut être trop long pour se positionner dans l’interface utilisateur ou peut être utile uniquement pour les nouveaux utilisateurs, se sentant comme un encombrement pour les utilisateurs expérimentés. Dans ce cas, le texte d’instruction/d’information doit être placé en tant qu’info-bulle sous info-bulle.

Les informations Astuces doivent être placées près des contrôles auxquels ils sont liés et doivent utiliser l’icône info-bulle spécifique, ce qui n’est pas visible.

Exemple d’info-bulle dans Visual Studio

Mécanismes d’aide interactifs

Aide (F1)

L’aide F1 est requise dans un éditeur ou une aire de conception, mais pas ailleurs dans l’environnement Visual Studio.

Liens hypertexte vers les rubriques d’aide

Les liens hypertexte peuvent être utilisés pour effectuer une action, naviguer dans l’IDE ou lancer l’aide dans un navigateur. Consultez le texte et la terminologie de l’interface utilisateur pour plus d’informations sur la langue et les boutons et liens hypertexte 07.10.01 pour obtenir des instructions relatives aux visuels et à la disposition.

Boutons d’aide [ ?] dans les barres de titre de boîte de dialogue (déconseillées)

Pour la plupart, les boutons d’aide [ ?] dans la barre de titre des boîtes de dialogue sont déconseillés. Les rubriques de l’interface utilisateur ne font plus partie de notre modèle de documentation, et par conséquent, il se peut qu’il n’y ait pas de rubrique pertinente à laquelle lier. Essentiellement, le bouton de la barre de titre était la même chose que l’aide F1, et cela n’est plus nécessaire dans les boîtes de dialogue. Dans certains cas, cela peut toujours être utilisé comme indicateur qu’il existe plus d’informations conceptuelles ou procédurales disponibles, bien que les liens hypertexte soient plus couramment utilisés dans une interface utilisateur plus récente.

Boîtes de dialogue créées via l’environnement

De nombreux dialogues d’interpréteur de commandes sont créés via la fonction VBDialogBoxParam . Cette fonction partagée a été mise à jour pour aider à déplacer le bouton d’aide de la boîte de dialogue vers le bouton ? tout en conservant une architecture compatible descendante et extensible.

Plus précisément, la fonction VBDialogBoxParam examine le modèle de boîte de dialogue d’un bouton dont l’ID est IDHELP (9) ou l’étiquette est Aide ou &Aide. Si un bouton d’aide est trouvé, il est masqué et le style WS_EX_CONTEXTHELP est ajouté à la boîte de dialogue, qui place le bouton ? dans la barre de titre du dialogue.

Lorsque le dialogue est créé, il envoie le processus de dialogue sur une pile et appelle le dialogue avec un processus de dialogue de prétraitement nommé DialogPreProc. Lorsque le bouton ? est cliqué, il envoie une WM_SYSCOMMAND de SC_CONTEXTHELP à la boîte de dialogue. DialogPreProc capture cette commande et la remplace par un message WM_HELP qui est passé à la procédure de dialogue d’origine.

La plupart des dialogues créés par l’environnement ont un bouton Aide dans la boîte de dialogue. Lorsque la boîte de dialogue s’affiche, le bouton Aide est masqué automatiquement et seul le bouton ? fonctionne. Si le bouton ? est déjà supprimé ou modifié dans Windows, cette solution vous permet de revenir rapidement aux boutons d’aide d’origine.

Cette solution fait quatre hypothèses susceptibles de provoquer des bogues :

• Le bouton d’aide de la boîte de dialogue est IDHELP (9).

• La boîte de dialogue semble correcte lorsque le bouton Aide est masqué.

• Le dialogue ne remplace pas son winproc.

• Le dialogue n’est pas incorporé à l’intérieur d’un autre dialogue.

  Si votre boîte de dialogue réside dans msenv et n’utilise pas VBDialogBoxParam, examinez l’utilisation de VBDialogBoxParam avant d’implémenter votre propre gestionnaire.

Boîtes de dialogue créées via d’autres packages

Vous pouvez implémenter votre propre solution pour les dialogues qui résident en dehors de msenv. Pour une classe de dialogue partagée dans votre VSPackage, envisagez de déplacer le bouton vers la barre de titre ou d’implémenter un gestionnaire sur chaque boîte de dialogue. Le code suivant est un squelette d’une implémentation pour vous aider à commencer :

struct DLGPROCITEM
{
    FARPROC proc; // The info used to create the dialog.
    DLGPROCITEM* procPrev;
};

DLGPROCITEM* g_dlgProcStack = NULL;

// A dialog starter/wrapper function is used to push the new
// dialog proc to the top of our dialog proc stack.

int SomeDialogStarterFunction(hinst, id, proc, etc)
{
    if (g_dlgProcStack == NULL)
    {
        g_dlgProcStack = new DLGPROCITEM;
        g_dlgProcStack->procPrev = NULL;
    }
    else
    {
        DLGPROCITEM* procItem = new DLGPROCITEM;
        g_dlgProcStack->procPrev = g_dlgProcStack;
        g_dlgProcStack = procItem;
    }
}

// Pop this dialog proc off the dialog proc stack.

DialogBoxIndirectParam...(...)
{
    DLGPROCITEM* procItem = g_dlgProcStack->procPrev;
    delete g_dlgProcStack;
    g_dlgProcStack = procItem;
}

// A wrapper dialog procedure will allow us to capture the
// SC_CONTEXTHELP button on the title bar from Windows and
// forward it as a simple WM_HELP message back to the dialog.

INT_PTR CALLBACK DialogPreProc(HWND hwndDlg, UINT uMsg,
    WPARAM wParam, LPARAM lParam)
{
    if (uMsg == WM_SYSCOMMAND && wParam == SC_CONTEXTHELP)
    {
        uMsg = WM_HELP;
        wParam = 0;
        lParam = 0;
    }
    return CallWindowProc((WNDPROC)g_dlgProcStack->proc,
        hwndDlg, uMsg, wParam, lParam);
}

Boutons d’aide dans le code managé

La substitution du comportement par défaut du bouton d’aide de la barre de titre de fenêtre est facile dans le code managé. Vous trouverez ci-dessous une application de démonstration complète qui illustre ce comportement. En essence, vous devez remplacer la méthode WndProc de votre formulaire, puis désactiver les demandes d’aide F1 lorsqu’un message SC_CONTEXTHELP est intercepté.

using System;
using System.Windows.Forms;

public class HelpForm : Form
{
    private const int SC_CONTEXTHELP = 0xF180;
    private const int WM_SYSCOMMAND = 0x0112;

    public HelpForm()
    {
        this.ClientSize = new System.Drawing.Size(300, 250);
        this.HelpButton = true;
        this.MaximizeBox = false;
        this.MinimizeBox = false;
        this.Name = "HelpForm";
        this.Text = "Help Form";
    }

    protected override void WndProc(ref Message m)
    {
        if (m.Msg == WM_SYSCOMMAND && SC_CONTEXTHELP == (int)m.WParam)
            ShowHelp();
        else
            base.WndProc(ref m);
    }

    private void ShowHelp()
    {
        MessageBox.Show("F1 Help goes here.");
    }

     [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.EnableRTLMirroring();
        Application.Run(new HelpForm());
    }
}

Voir aussi

• Polices et mise en forme pour Visual Studio
• Présentation pour Visual Studio
• Notifications et progression pour Visual Studio