Modèles d’application pour Visual Studio
Interactions de fenêtre
Les deux types de fenêtre principaux utilisés dans Visual Studio sont des éditeurs de documents et des fenêtres d’outils. Rares, mais possibles, sont de grands dialogues sans mode. Bien qu’ils soient tous sans mode dans l’interpréteur de commandes, leurs modèles sont fondamentalement différents. Cette section décrit la différence entre les fenêtres de document, les fenêtres d’outils et les boîtes de dialogue sans mode. Les modèles de dialogue modal sont abordés dans les dialogues.
Comparaison des modèles d’utilisation des fenêtres
Les fenêtres de document sont presque toujours affichées dans le document. Cela donne à l’éditeur de document une « phase centrale » pour organiser des fenêtres d’outils supplémentaires autour.
Une fenêtre outil s’affiche le plus souvent sous la forme d’une fenêtre distincte et plus petite réduite par rapport au bord de l’IDE. Cela peut être visible, masqué ou masqué automatiquement. Toutefois, parfois, les fenêtres d’outils sont présentées dans le document bien, en un case activée la propriété Window/Docking sur la fenêtre. Cela entraîne davantage d’immobiliers, mais également une décision de conception commune : lorsque vous tentez d’intégrer dans Visual Studio, vous devez décider si votre fonctionnalité doit afficher une fenêtre outil ou une fenêtre de document.
Les boîtes de dialogue sans mode sont déconseillées dans Visual Studio. La plupart des dialogues sans mode sont, par définition, des fenêtres d’outils flottantes et doivent être implémentées de cette façon. Les boîtes de dialogue sans mode sont autorisées dans les cas où la taille d’une fenêtre d’outil normale ancrée sur le côté de l’interpréteur de commandes serait trop limitée. Ils sont également autorisés dans les cas où l’utilisateur serait susceptible de déplacer la boîte de dialogue vers un moniteur secondaire.
Réfléchissez soigneusement au type de conteneur dont vous avez besoin. Les considérations courantes relatives au modèle d’utilisation pour la conception de l’interface utilisateur se trouvent dans le tableau suivant.
| Fenêtre document | Fenêtre Outil | Boîte de dialogue sans mode | |
|---|---|---|---|
| Poste | Toujours positionné dans le document bien et ne s’ancre pas autour des bords de l’IDE. Il peut être « tiré » afin qu’il flotte séparément de l’interpréteur de commandes principal. | En règle générale, les onglets ancrés autour des bords de l’IDE peuvent être personnalisés pour être flottants, masqués automatiquement (non épinglé) ou ancrés dans le document. | Grande fenêtre flottante séparée de l’IDE. |
| Valider le modèle | Validation différée Pour enregistrer les données dans un document, l’utilisateur doit émettre la > commande Enregistrer, Enregistrer sous ou Enregistrer tout. Une fenêtre de document a le concept des données qu’elle contient étant « salesied », puis validée dans l’une des commandes d’enregistrement. Lors de la fermeture d’une fenêtre de document, tout le contenu est enregistré sur le disque ou perdu. |
Validation immédiate Il n’existe aucun modèle d’enregistrement. Pour les fenêtres d’outil d’inspecteur qui aident à modifier un fichier, le fichier doit être ouvert dans l’éditeur ou le concepteur actif, et l’éditeur ou le concepteur possède l’enregistrement. |
Validation différée ou immédiate Le plus souvent, une boîte de dialogue sans mode volumineuse nécessite une action pour valider les modifications et permet une opération « Annuler », qui restaure les modifications apportées dans la session de dialogue. Cela différencie une boîte de dialogue sans mode d’une fenêtre d’outil dans cette fenêtre outil a toujours un modèle de validation immédiate. |
| Visibilité | Ouvrir/créer (fichier) et fermer L’ouverture d’une fenêtre de document s’effectue via l’ouverture d’un document existant ou l’utilisation d’un modèle pour créer un document. Il n’existe aucune commande « Ouvrir <un éditeur> spécifique ». |
Masquer et afficher Les fenêtres outil à instance unique peuvent être masquées ou affichées. Le contenu et les états dans la fenêtre outil persistent, qu’ils soient affichés ou masqués. Les fenêtres d’outils multi-instances peuvent être fermées et masquées. Lorsqu’une fenêtre d’outil multi-instance est fermée, le contenu et l’état dans la fenêtre outil sont désactivés carte. |
Lancé à partir d’une commande Les boîtes de dialogue sont lancées à partir d’une commande basée sur des tâches. |
| Instances | Multi-instance Plusieurs éditeurs peuvent être ouverts en même temps et modifier différents fichiers, tandis que certains éditeurs permettent également l’ouverture du même fichier dans plusieurs éditeurs (à l’aide de la commande Fenêtre > Nouvelle fenêtre ). Un seul éditeur peut modifier un ou plusieurs fichiers en même temps (Concepteur de projets). |
Instance unique ou multi-instance Le contenu change pour refléter le contexte (comme dans l’Explorateur de propriétés) ou envoyer (push) le focus/contexte vers d’autres fenêtres (Liste des tâches, Explorateur de solutions). Les fenêtres outil à instance unique et multi-instance doivent être associées à la fenêtre de document active, sauf s’il existe une raison convaincante de ne pas le faire. |
Instance unique |
| Exemples | Éditeurs de texte, comme l’éditeur de code Concevoir des surfaces, comme un concepteur de formulaires ou une surface de modélisation Contrôles similaires aux boîtes de dialogue, comme le Concepteur de manifestes |
Le Explorateur de solutions fournit une solution et des projets contenus dans la solution L’Explorateur de serveurs fournit une vue hiérarchique des serveurs et des connexions de données que l’utilisateur choisit d’ouvrir dans la fenêtre. L’ouverture d’un objet à partir de la hiérarchie de base de données, comme une requête, ouvre une fenêtre de document et permet à l’utilisateur de modifier la requête. L’Explorateur de propriétés affiche les propriétés de l’objet sélectionné dans une fenêtre de document ou une autre fenêtre d’outil. Les propriétés sont présentées dans une vue de grille hiérarchique ou dans des contrôles complexes de type dialogue et permettent à l’utilisateur de définir les valeurs de ces propriétés. |
Fenêtres d’outil
Les fenêtres outil prennent en charge le travail de l’utilisateur qui se produit dans les fenêtres de document. Ils peuvent être utilisés pour afficher une hiérarchie qui représente un objet racine fondamental fourni par Visual Studio et peut manipuler.
Lorsque vous envisagez une nouvelle fenêtre d’outil dans l’IDE, les auteurs doivent :
Utilisez les fenêtres d’outils existantes appropriées aux tâches et ne créez pas de nouvelles fenêtres avec des fonctionnalités similaires. Les fenêtres d’outils ne doivent être créées que si elles offrent un « outil » ou une fonctionnalité sensiblement différent qui ne peut pas être intégré à une fenêtre similaire, ou en transformant une fenêtre existante en hub croisé dynamique.
Utilisez une barre de commandes standard, si nécessaire, en haut de la fenêtre outil.
Soyez cohérent avec les modèles déjà présents dans d’autres fenêtres d’outils pour contrôler la présentation et la navigation au clavier.
Soyez cohérent avec la présentation de contrôle dans d’autres fenêtres d’outils.
Rendre les fenêtres d’outils spécifiques au document visibles automatiquement lorsque cela est possible, de sorte qu’elles apparaissent uniquement lorsque le document parent est activé.
Vérifiez que leur contenu de fenêtre est navigable par le clavier (prendre en charge les touches de direction).
États de la fenêtre outil
Les fenêtres d’outils Visual Studio ont des états différents, dont certains sont activés par l’utilisateur (comme la fonctionnalité de masquage automatique). D’autres états, tels que l’affichage automatique, permettent aux fenêtres d’outils d’apparaître dans le contexte approprié et de masquer le cas échéant. Il existe cinq états de fenêtre d’outils au total.
Les fenêtres d’outils ancrées/épinglées peuvent être attachées à l’un des quatre côtés de la zone de document. L’icône d’épingle s’affiche dans la barre de titre de la fenêtre outil. La fenêtre outil peut être ancrée horizontalement ou verticalement le long du bord de l’interpréteur de commandes et d’autres fenêtres d’outils, et peut également être liée par tabulation.
Les fenêtres d’outils masquées automatiquement ne sont pas épinglé. La fenêtre peut glisser hors de vue, en laissant un onglet (avec le nom de la fenêtre outil et son icône) sur le bord de la zone de document. La fenêtre outil s’affiche lorsqu’un utilisateur pointe sur l’onglet.
Les fenêtres d’outils visibles automatiquement s’affichent automatiquement quand un autre élément d’interface utilisateur, tel qu’un éditeur, est lancé ou obtient le focus.
Les fenêtres de l’outil flottant pointent en dehors de l’IDE. Cela est utile pour les configurations multi-moniteurs.
Les fenêtres de l’outil de document à onglets peuvent être ancrées dans le document. Cela est utile pour les grandes fenêtres d’outils, comme l’Explorateur d’objets, qui ont besoin de plus d’immobilier que d’ancrage sur les bords du cadre permet.
États de la fenêtre Outil dans Visual Studio
Instance unique et multi-instance
Les fenêtres d’outils sont à instance unique ou à plusieurs instances. Certaines fenêtres d’outils à instance unique peuvent être associées à la fenêtre de document active, tandis que les fenêtres d’outils multi-instances peuvent ne pas être associées. Les fenêtres outil multi-instances répondent à la commande Fenêtre > Nouvelle fenêtre en créant une nouvelle instance de la fenêtre. L’image suivante illustre une fenêtre d’outil activant la commande Nouvelle fenêtre lorsqu’une instance de la fenêtre est active :
Fenêtre outil activant la commande « Nouvelle fenêtre » lorsqu’une instance de la fenêtre est active
Les fenêtres d’outils à instance unique peuvent être masquées ou affichées, tandis que les fenêtres d’outils multi-instances peuvent être fermées et masquées. Toutes les fenêtres d’outils peuvent être ancrées, liées à des onglets, flottantes ou définies en tant que fenêtre enfant MDI (Multiple-Document Interface) (similaire à une fenêtre de document). Toutes les fenêtres d’outils doivent répondre aux commandes de gestion des fenêtres appropriées dans le menu Fenêtre :
Commandes de gestion des fenêtres dans le menu Fenêtre Visual Studio
Fenêtres d’outils spécifiques au document
Certaines fenêtres d’outils sont conçues pour changer en fonction d’un type donné de document. Ces fenêtres sont continuellement mises à jour pour refléter les fonctionnalités applicables à la fenêtre de document active dans l’IDE.
Exemples de fenêtres d’outils dont le contenu change pour refléter l’éditeur sélectionné est la boîte à outils et le plan du document. Ces fenêtres affichent un filigrane lorsqu’un éditeur a le focus qui n’offre pas de contexte à la fenêtre.
Fenêtres de l’outil de liste navigable
Certaines fenêtres d’outils affichent une liste d’éléments navigables avec lesquels l’utilisateur peut interagir. Dans ce type de fenêtre, il doit toujours y avoir des commentaires pour l’élément actif dans la liste, même si la fenêtre est inactive. La liste doit répondre aux commandes GoToNextLocation et GoToPrevLocation en modifiant également l’élément actuellement sélectionné dans la fenêtre
Les fenêtres des outils de liste navigable sont les Explorateur de solutions et la fenêtre Résultats de la recherche.
Types de fenêtre d’outils
Fenêtres d’outils courantes et leurs fonctions
Fenêtres d’outils hiérarchiques
| Fenêtre Outil | Fonction |
|---|---|
| Explorateur de solutions | Arborescence hiérarchique qui affiche une liste de documents contenus dans des projets, des fichiers divers et des éléments de solution. L’affichage des éléments au sein des projets est défini par le package qui possède le type de projet (par exemple, les types basés sur des références, basés sur un répertoire ou en mode mixte). |
| Affichage de classes | Arborescence hiérarchique des classes et différents éléments dans le jeu de documents de travail, indépendamment des fichiers eux-mêmes. |
| Explorateur de serveurs | Arborescence hiérarchique qui affiche tous les serveurs et connexions de données dans la solution. |
| Structure du document | Structure hiérarchique du document actif. |
Fenêtres de l’outil Grille
| Fenêtre Outil | Fonction |
|---|---|
| Propriétés | Grille qui affiche une liste de propriétés pour l’objet sélectionné, ainsi que des sélecteurs de valeurs pour modifier ces propriétés. |
| Liste des tâches | Grille qui permet à l’utilisateur de créer/modifier/supprimer des tâches et des commentaires. |
Fenêtres outil de contenu
| Fenêtre Outil | Fonction |
|---|---|
| Aide | Fenêtre qui permet aux utilisateurs d’accéder à différentes méthodes d’aide, de « Comment faire ? » aux forums MSDN. |
| Aide dynamique | Fenêtre d’outil qui affiche des liens vers des rubriques d’aide applicables à la sélection actuelle. |
| Explorateur d'objets | Un jeu de cadres à deux colonnes avec une liste de composants d’objet hiérarchiques dans le volet gauche et les propriétés et méthodes de l’objet dans la colonne droite. |
Fenêtres de l’outil de boîte de dialogue
| Fenêtre Outil | Fonction |
|---|---|
| Rechercher | Boîte de dialogue qui permet à l’utilisateur de rechercher ou de rechercher et de remplacer dans différents fichiers au sein de la solution. |
| Recherche avancée | Boîte de dialogue qui permet à l’utilisateur de rechercher ou de rechercher et de remplacer dans différents fichiers au sein de la solution. |
Autres fenêtres d’outils
| Fenêtre Outil | Fonction |
|---|---|
| Boîte à outils | Fenêtre outil utilisée pour stocker des éléments qui seront déposés sur des surfaces de conception, fournissant une source de glisser cohérente pour tous les concepteurs. |
Fenêtres de l’outil débogueur
| Fenêtre Outil | Fonction |
|---|---|
| Autos | |
| Immédiat | |
| Sortie | La fenêtre de sortie peut être utilisée chaque fois que vous avez des événements textuels ou un état à déclarer. |
| Mémoire | |
| Points d’arrêt | |
| En cours d’exécution | |
| Documents | |
| Pile des appels | |
| Variables locales | |
| Regarde | |
| Code Machine | |
| Caisses | |
| Threads |
Conventions de l’éditeur de documents
Interactions de document
Le « document bien » est le plus grand espace au sein de l’IDE et c’est là que l’utilisateur a généralement concentré son attention pour effectuer ses tâches, assisté par des fenêtres d’outils supplémentaires. Les éditeurs de documents représentent les unités de travail fondamentales que l’utilisateur ouvre et enregistre dans Visual Studio. Ils conservent un fort sentiment de sélection lié à Explorateur de solutions ou à d’autres fenêtres de hiérarchie active. L’utilisateur doit pouvoir pointer vers l’une de ces fenêtres de hiérarchie et savoir où le document est contenu et sa relation avec la solution, le projet ou un autre objet racine fourni par un package Visual Studio.
La modification de document nécessite une expérience utilisateur cohérente. Pour permettre à l’utilisateur de se concentrer sur la tâche à la place de la gestion des fenêtres et de rechercher des commandes, sélectionnez une stratégie d’affichage de document qui correspond le mieux aux tâches utilisateur pour modifier ce type de document.
Interactions courantes pour le document bien
Conservez un modèle d’interaction cohérent dans les expériences courantes New File and Open File .
Mettez à jour les fonctionnalités associées dans les fenêtres et menus associés lorsque la fenêtre de document s’ouvre.
Les commandes de menu sont correctement intégrées aux menus courants tels que Modifier, Mettre en forme et Afficher les menus. Si une quantité importante de commandes spécialisées est disponible, un nouveau menu peut être créé. Ce nouveau menu ne doit être visible que lorsque le document a le focus.
Une barre d’outils incorporée peut être placée en haut de l’éditeur. Il est préférable d’avoir une barre d’outils distincte qui s’affiche en dehors de l’éditeur.
Conservez toujours une sélection dans la fenêtre de hiérarchie active Explorateur de solutions ou similaire.
Le double-clic sur un document dans le Explorateur de solutions doit effectuer la même action que Ouvrir.
Si plusieurs éditeurs peuvent être utilisés sur un type de document, l’utilisateur doit pouvoir remplacer ou réinitialiser l’action par défaut sur un type de document donné à l’aide de la boîte de dialogue Ouvrir avec en cliquant avec le bouton droit sur le fichier et en sélectionnant Ouvrir avec dans le menu contextuel.
Ne créez pas d’Assistant dans un document correctement.
Attentes des utilisateurs pour des types de documents spécifiques
Il existe plusieurs types de base différents d’éditeurs de documents et chacun a un ensemble d’interactions qui sont cohérentes avec d’autres types de même type.
Éditeur de texte : éditeur de code, fichiers journaux
Aire de conception : concepteur de formulaires WPF, Windows Forms
Éditeur de style de boîte de dialogue : Concepteur de manifeste, propriétés du projet
Concepteur de modèles : concepteur de flux de travail, codemap, diagramme d’architecture, progression
Il existe également plusieurs types non éditeurs qui utilisent bien le document. Bien qu’ils ne modifient pas eux-mêmes les documents, ils doivent suivre les interactions standard pour les fenêtres de documents.
Rapports : rapport IntelliTrace, rapport Hyper-V, rapport profileur
Tableau de bord : Diagnostics Hub
Éditeurs basés sur du texte
Le document participe au modèle d’onglet d’aperçu, ce qui permet d’afficher un aperçu du document sans l’ouvrir.
La structure du document peut être représentée dans une fenêtre d’outil complémentaire, telle qu’un plan de document.
IntelliSense (le cas échéant) se comporte de manière cohérente avec d’autres éditeurs de code.
Les fenêtres contextuelles ou l’interface utilisateur d’assistance suivent des styles et des modèles similaires pour l’interface utilisateur similaire existante, comme CodeLens.
Les messages concernant l’état du document sont présentés dans un contrôle de barre d’informations en haut du document ou dans la barre d’état.
L’utilisateur doit pouvoir personnaliser l’apparence des polices et des couleurs à l’aide d’une page Options d’outils>, soit la page Polices et couleurs partagées, soit une page spécifique à l’éditeur.
Surfaces de conception
Un concepteur vide doit avoir un filigrane sur la surface indiquant comment commencer.
Les mécanismes de basculement d’affichage suivent les modèles existants, tels que le double-clic pour ouvrir un éditeur de code ou des onglets dans la fenêtre de document, ce qui permet l’interaction avec les deux volets.
L’ajout d’éléments à l’aire de conception doit être effectué via la boîte à outils, sauf si une fenêtre d’outil hautement spécifique est requise.
Les éléments de la surface suivent un modèle de sélection cohérent.
Les barres d’outils incorporées contiennent uniquement des commandes spécifiques au document, et non des commandes courantes telles que Enregistrer.
Éditeurs de style de boîte de dialogue
La disposition du contrôle doit suivre les conventions normales de disposition de boîte de dialogue.
Les onglets de l’éditeur ne doivent pas correspondre à l’apparence des onglets du document, ils doivent correspondre à l’un des deux styles d’onglet intérieur autorisés.
Les utilisateurs doivent être en mesure d’interagir avec les contrôles à l’aide du clavier uniquement ; soit en activant l’éditeur et le tabulation par le biais de contrôles, soit en utilisant des mnémoniques standard.
Le concepteur doit utiliser le modèle d’enregistrement commun. Aucun bouton d’enregistrement ou de validation global ne doit être placé sur la surface, bien que d’autres boutons puissent être appropriés.
Concepteurs de modèles
Un concepteur vide doit avoir un filigrane sur la surface indiquant comment commencer.
L’ajout d’éléments à l’aire de conception doit être effectué via la boîte à outils.
Les éléments de la surface suivent un modèle de sélection cohérent.
Les barres d’outils incorporées contiennent uniquement des commandes spécifiques au document, et non des commandes courantes telles que Enregistrer.
Une légende peut apparaître sur la surface, indicatif ou filigrane.
L’utilisateur doit pouvoir personnaliser l’apparence des polices/couleurs à l’aide d’une page Options d’outils>, de polices et de couleurs partagées ou d’une page spécifique à l’éditeur.
Rapports
Les rapports sont généralement des informations uniquement et ne participent pas au modèle d’enregistrement. Toutefois, elles peuvent inclure des interactions telles que des liens vers d’autres informations ou sections pertinentes qui s’étendent et s’réduisent.
La plupart des commandes sur l’aire doivent être des liens hypertexte, et non des boutons.
La disposition doit inclure un en-tête et suivre les instructions de disposition de rapport standard.
Tableaux de bord
Les tableaux de bord n’ont pas de modèle d’interaction eux-mêmes, mais servent de moyen d’offrir une variété d’autres outils.
Ils ne participent pas au modèle Enregistrer.
Les utilisateurs doivent être en mesure d’interagir avec les contrôles à l’aide du clavier uniquement, soit en activant l’éditeur et tabulation par le biais de contrôles, soit en utilisant des mnémoniques standard.
Boîtes de dialogue
Introduction
Les boîtes de dialogue dans Visual Studio doivent généralement prendre en charge une unité discrète du travail de l’utilisateur, puis être ignorées.
Si vous avez déterminé que vous avez besoin d’une boîte de dialogue, vous avez trois choix, dans l’ordre de préférence :
Intégrez vos fonctionnalités à l’une des boîtes de dialogue partagées dans Visual Studio.
Créez votre propre boîte de dialogue à l’aide d’un modèle trouvé dans un dialogue similaire existant.
Créez une boîte de dialogue, en suivant les instructions d’interaction et de disposition.
Cette section explique comment choisir le modèle de dialogue approprié dans les flux de travail Visual Studio et les conventions courantes pour la conception de dialogue.
Thèmes
Les boîtes de dialogue dans Visual Studio suivent l’un des deux styles de base suivants :
Standard (non jugé)
La majorité des dialogues sont des dialogues utilitaires standard et doivent être considérés comme non considérés. Ne recréez pas les contrôles courants ni tentez de créer des boutons ou des contrôles « modernes » stylisés. Les contrôles et l’apparence chrome suivent les instructions d’interaction standard du Bureau Windows pour les boîtes de dialogue.
Thème
Les dialogues « signature » spécialisés peuvent être thématiques. Les dialogues à thème ont une apparence distincte, qui a également des modèles d’interaction spéciaux associés au style. Thèmez votre boîte de dialogue uniquement si elle répond à ces exigences :
La boîte de dialogue est une expérience courante qui sera vue et utilisée souvent ou par de nombreux utilisateurs (par exemple, la boîte de dialogue Nouveau projet .
La boîte de dialogue contient des éléments de marque de produit importants (par exemple, la boîte de dialogue Compte Paramètres).
La boîte de dialogue s’affiche dans le cadre d’un flux plus large qui inclut d’autres dialogues thématiques (par exemple, la boîte de dialogue Ajouter un service Connecter ed).
Le dialogue est une partie importante d’une expérience qui joue un rôle stratégique dans la promotion ou la différenciation d’une version de produit.
Lors de la création d’une boîte de dialogue à thème, utilisez les couleurs d’environnement appropriées et suivez les modèles de disposition et d’interaction appropriés. (Voir Disposition de Visual Studio.)
Conception de boîte de dialogue
Les dialogues bien conçus prennent en compte les éléments suivants :
Tâche utilisateur prise en charge
Style de texte, langue et terminologie de la boîte de dialogue
Contrôler les conventions de choix et d’interface utilisateur
Spécification de disposition visuelle et alignement des contrôles
Accès par le clavier
Organisation du contenu
Tenez compte des différences entre ces types de dialogues de base :
Les boîtes de dialogue simples présentent des contrôles dans une seule fenêtre modale. La présentation peut inclure des variantes de modèles de contrôle complexes, notamment un sélecteur de champs ou une barre d’icônes.
Les dialogues en couches sont utilisés pour tirer le meilleur parti de l’immobilier d’écran lorsqu’un seul élément d’interface utilisateur comprend plusieurs groupes de contrôles. Les regroupements de la boîte de dialogue sont « superposés » par le biais de contrôles onglets, de contrôles de liste de navigation ou de boutons afin que l’utilisateur puisse choisir le regroupement à afficher à un moment donné.
Les Assistants sont utiles pour diriger l’utilisateur via une séquence logique d’étapes vers l’achèvement d’une tâche. Une série de choix est proposée dans des panneaux séquentiels, parfois en introduisant différents flux de travail (« branches ») en fonction d’un choix fait dans le volet précédent.
Boîtes de dialogue simples
Une boîte de dialogue simple est une présentation des contrôles dans une seule fenêtre modale. Cette présentation peut inclure des variantes de modèles de contrôle complexes, comme un sélecteur de champs. Pour les dialogues simples, suivez la disposition générale standard ainsi que toute disposition spécifique requise pour les regroupements de contrôles complexes.
Créer une clé de nom fort est un exemple de boîte de dialogue simple dans Visual Studio.
Boîtes de dialogue en couches
Les dialogues en couches incluent des onglets, des tableaux de bord et des arborescences incorporées. Ils sont utilisés pour optimiser l’immobilier lorsqu’il existe plusieurs groupes de contrôles proposés dans une seule partie de l’interface utilisateur. Les regroupements sont superposés afin que l’utilisateur puisse choisir le regroupement à afficher à tout moment.
Dans le cas le plus simple, le mécanisme de basculement entre les regroupements est un contrôle tabulation. Il existe plusieurs alternatives disponibles. Consultez Hiérarchisation et superposition pour savoir comment choisir le style le plus approprié.
La boîte de dialogue Options des outils > est un exemple de dialogue en couches à l’aide d’une arborescence incorporée :
Options d’outils > est un exemple de boîte de dialogue en couches dans Visual Studio.
Assistants
Les Assistants sont utiles pour diriger l’utilisateur via une séquence logique d’étapes dans l’achèvement d’une tâche. Une série de choix est proposée dans des panneaux séquentiels, et l’utilisateur doit passer à chaque étape avant de passer à la suivante. Une fois les valeurs par défaut suffisantes disponibles, le bouton Terminer est activé.
Les Assistants modals sont utilisés pour les tâches qui :
Contenir des branches, où différents chemins d’accès sont proposés en fonction des choix d’utilisateur
Contenir des dépendances entre les étapes, où les étapes suivantes dépendent de l’entrée utilisateur de la ou des étapes précédentes
Sont suffisamment complexes que l’interface utilisateur doit être utilisée pour expliquer les choix offerts et les résultats possibles dans chaque étape
Sont transactionnels, nécessitant l’exécution d’un ensemble d’étapes dans son intégralité avant que les modifications ne soient validées
Conventions courantes
Pour obtenir une conception et des fonctionnalités optimales avec vos dialogues, suivez ces conventions sur la taille, la position, les normes, la configuration et l’alignement des contrôles, le texte de l’interface utilisateur, les barres de titre, les boutons de contrôle et les touches d’accès.
Pour obtenir des instructions spécifiques à la disposition, consultez Disposition pour Visual Studio.
Taille
Les boîtes de dialogue doivent correspondre à une résolution d’écran minimale de 1024 x 768, et la taille initiale de la boîte de dialogue ne doit pas dépasser 900 x 700 pixels. Les dialogues peuvent être redimensionnables, mais ce n’est pas obligatoire.
Il existe deux recommandations pour les dialogues redimensionnables :
Qu’une taille minimale est définie pour la boîte de dialogue qui optimisera le jeu de contrôles sans découpage, et s’ajuste pour prendre en charge une croissance de localisation raisonnable.
Que la taille mise à l’échelle de l’utilisateur persiste de la session à la session. Par exemple, si l’utilisateur met à l’échelle une boîte de dialogue à 150 %, un lancement ultérieur de la boîte de dialogue s’affiche à 150 %.
Position
Les boîtes de dialogue doivent apparaître centrées dans l’IDE lors du premier lancement. La dernière position des dialogues non redimensionnables n’a pas besoin d’être conservée, de sorte qu’elles apparaissent centrées sur les lancements suivants.
Pour les dialogues redimensionnables, la taille doit être conservée lors des lancements suivants. Pour les boîtes de dialogue modales redimensionnables, la position n’a pas besoin d’être conservée. L’affichage de ces éléments centrés dans l’IDE empêche la possibilité que la boîte de dialogue s’affiche dans une position imprévisible ou inutilisable lorsque la configuration d’affichage de l’utilisateur a changé.
Pour les dialogues sans mode qui peuvent être repositionnés, la position de l’utilisateur doit être conservée lors des lancements suivants, car la boîte de dialogue peut être utilisée fréquemment comme partie intégrante d’un flux de travail plus volumineux.
Lorsque les dialogues doivent générer d’autres dialogues, le dialogue le plus haut doit se mettre en cascade à droite et vers le bas du parent afin qu’il soit évident à l’utilisateur qu’il a accédé à un nouvel emplacement.
Modalité
Être modal signifie que les utilisateurs doivent terminer ou annuler la boîte de dialogue avant de continuer. Dans la mesure où les boîtes de dialogue modales empêchent l’utilisateur d’interagir avec d’autres parties de l’environnement, le flux de tâches de votre fonctionnalité doit les utiliser de manière aussi éparse que possible. Quand une opération modale est nécessaire, Visual Studio dispose d’un certain nombre de boîtes de dialogue partagées dans lesquelles vous pouvez intégrer vos fonctionnalités. Si vous devez créer un dialogue, suivez le modèle d’interaction d’un dialogue existant avec des fonctionnalités similaires.
Lorsque les utilisateurs doivent effectuer deux activités à la fois, telles que Rechercher et remplacer lors de l’écriture de nouveau code, la boîte de dialogue doit être sans mode afin que l’utilisateur puisse facilement basculer entre eux. Visual Studio utilise généralement les fenêtres d’outils pour ce type de tâche liée prenant en charge l’éditeur.
Configuration du contrôle
Soyez cohérent avec les configurations de contrôle existantes qui effectuent la même chose dans Visual Studio.
Barres de titre
Le texte de la barre de titre doit refléter le nom de la commande qui l’a lancée.
Aucune icône ne doit être utilisée dans les barres de titre de boîte de dialogue. Dans les cas où le système en a besoin un, utilisez le logo Visual Studio.
Les boîtes de dialogue ne doivent pas comporter de boutons de réduction ou d’agrandissement.
Les boutons d’aide dans la barre de titre ont été déconseillés. Ne les ajoutez pas aux nouvelles boîtes de dialogue. Lorsqu’ils existent, ils doivent lancer une rubrique d’aide qui est conceptuellement pertinente pour la tâche.
Spécifications des instructions pour les barres de titre dans les boîtes de dialogue Visual Studio
Boutons de contrôle
En général, les boutons OK, Annuler et Aide doivent être organisés horizontalement dans le coin inférieur droit de la boîte de dialogue. La pile verticale alternative est autorisée si un dialogue comporte plusieurs autres boutons en bas de la boîte de dialogue qui présentent une confusion visuelle avec les boutons de contrôle.
Configurations acceptables pour les boutons de contrôle dans les boîtes de dialogue Visual Studio
La boîte de dialogue doit inclure un bouton de contrôle par défaut. Pour déterminer la meilleure commande à utiliser comme valeur par défaut, choisissez parmi les options suivantes (répertoriées dans l’ordre de priorité) :
Choisissez la commande la plus sûre et la plus sécurisée comme valeur par défaut. Cela signifie que vous choisissez la commande la plus susceptible d’empêcher la perte de données et d’éviter l’accès involontaire au système.
Si la perte de données et la sécurité ne sont pas des facteurs, choisissez la commande par défaut en fonction de la commodité. L’inclusion de la commande la plus probable comme valeur par défaut améliore le flux de travail de l’utilisateur lorsque la boîte de dialogue prend en charge des tâches fréquentes ou répétitives.
Évitez de choisir une action destructrice permanente pour la commande par défaut. Si une telle commande est présente, choisissez plutôt une commande plus sûre comme valeur par défaut.
Clés d’accès
N’utilisez pas les clés d’accès pour les boutons OK, Annuler ou Aide . Ces boutons sont mappés aux touches de raccourci par défaut :
| Nom du bouton | Raccourci clavier |
|---|---|
| OK | Entrée |
| Annuler | Échap |
| Aide | F1 |
Imagerie
Utilisez des images avec parcimonie dans les dialogues. N’utilisez pas d’icônes volumineuses dans les boîtes de dialogue simplement pour utiliser de l’espace. Utilisez des images uniquement s’il s’agit d’une partie importante de la transmission du message à l’utilisateur, comme les icônes d’avertissement ou les animations d’état.
Hiérarchisation et superposition
Hiérarchisation de votre interface utilisateur
Il peut être nécessaire d’apporter certains éléments d’interface utilisateur à l’avant-plan et de placer des options et des comportements plus avancés (y compris des commandes obscures) dans des dialogues. Apportez la fonctionnalité couramment utilisée à la pointe en la rendant à la place et en la rendant visible par défaut dans l’interface utilisateur avec une étiquette de texte lorsque la boîte de dialogue est affichée.
Superposition de votre interface utilisateur
Si vous avez déterminé qu’un dialogue est nécessaire, mais que la fonctionnalité associée que vous souhaitez présenter à l’utilisateur va au-delà de ce qui peut être affiché dans une boîte de dialogue simple, vous devez calquer votre interface utilisateur. Les méthodes de superposition les plus courantes utilisées par Visual Studio sont des onglets et des couloirs ou des tableaux de bord. Dans certains cas, les régions qui peuvent se développer et s’réduire peuvent être appropriées. L’interface utilisateur adaptative n’est généralement pas recommandée dans Visual Studio.
Il existe des avantages et des inconvénients pour différentes méthodes d’interface utilisateur de couche par le biais de contrôles de type tabulation. Passez en revue la liste ci-dessous pour vous assurer que vous choisissez une technique de superposition appropriée à votre situation.
Tabulation
| Mécanisme de basculement | Avantages et utilisation appropriée | Inconvénients et utilisation inappropriée |
|---|---|---|
| Contrôle de tabulation | Regrouper logiquement des pages de boîte de dialogue dans des ensembles associés Utile pour moins de cinq (ou le nombre d’onglets qui tiennent dans une ligne dans la boîte de dialogue) pages de contrôles associés dans la boîte de dialogue Les étiquettes d’onglet doivent être courtes : un ou deux mots qui peuvent facilement identifier le contenu Style de boîte de dialogue système commun Exemple : propriétés d’élément > Explorateur de fichiers |
La création d’étiquettes courtes descriptives peut être difficile En règle générale, ne met pas à l’échelle cinq onglets dans une boîte de dialogue Inapproprié si vous avez trop d’onglets pour une ligne (utilisez une autre technique de superposition) Non extensible |
| Navigation dans la barre latérale | Appareil de basculement simple qui peut prendre en charge plus de catégories que d’onglets Liste plate des catégories (aucune hiérarchie) Extensible Exemple : Personnaliser... > Ajouter une commande |
Pas une bonne utilisation de l’espace horizontal s’il y a moins de trois groupes La tâche peut être mieux adaptée à une liste déroulante |
| Contrôle Tree | Permet des catégories illimitées Permet le regroupement et/ou la hiérarchie des catégories Extensible Exemple : Options des outils > |
Les hiérarchies fortement imbriquées peuvent entraîner un défilement horizontal excessif Visual Studio dispose d’une surabondance d’arborescences |
| Assistant | Aide à l’achèvement des tâches en guidant l’utilisateur via des étapes séquentielles basées sur des tâches : l’Assistant représente une tâche de haut niveau et les panneaux individuels représentent les tâches subordonnées nécessaires pour accomplir la tâche globale Utile lorsque la tâche dépasse les limites de l’interface utilisateur, comme si l’utilisateur aurait autrement besoin d’utiliser plusieurs éditeurs et fenêtres d’outils pour terminer la tâche Utile lorsque la tâche nécessite une branchement Utile lorsque la tâche contient des dépendances entre les étapes Utile lorsque plusieurs tâches similaires avec une duplication de décision peuvent être présentées dans un dialogue pour réduire le nombre de différents dialogues similaires |
Inapproprié pour toute tâche qui ne nécessite pas de flux de travail séquentiel Les utilisateurs peuvent devenir submergés et confus par un Assistant avec trop d’étapes Les Assistants ont intrinsèquement limité l’immobilier d’écran |
Couloirs ou tableaux de bord
Les couloirs et les tableaux de bord sont des dialogues ou des panneaux qui servent de points de lancement à d’autres dialogues et fenêtres. Le « couloir » bien conçu est immédiatement exposé uniquement aux options, commandes et paramètres les plus courants, ce qui permet à l’utilisateur d’accomplir facilement des tâches courantes. Comme un couloir réel fournit des portes pour accéder aux salles derrière eux, ici l’interface utilisateur moins commune est collectée dans des « salles » distinctes (souvent d’autres dialogues) de fonctionnalités connexes accessibles à partir du couloir principal.
Une interface utilisateur qui offre toutes les fonctionnalités disponibles dans une collection unique plutôt que de refactoriser les fonctionnalités les moins courantes dans des emplacements distincts est simplement un tableau de bord.
Concept hallway pour exposer une interface utilisateur supplémentaire dans Outlook
Interface utilisateur adaptative
L’affichage ou le masquage de l’interface utilisateur en fonction de l’utilisation ou de l’expérience auto-signalée d’un utilisateur est un autre moyen de présenter l’interface utilisateur nécessaire tout en masquant d’autres parties. Cela n’est pas recommandé dans Visual Studio, car les algorithmes pour décider quand afficher ou masquer l’interface utilisateur peuvent être difficiles, et les règles sont toujours incorrectes pour certains cas.
Projets
Projets dans le Explorateur de solutions
La plupart des projets sont classés comme basés sur des références, basés sur des annuaires ou mixtes. Les trois types de projets sont pris en charge simultanément dans le Explorateur de solutions. La racine de l’expérience utilisateur dans l’utilisation de projets se déroule à l’intérieur de cette fenêtre. Bien que différents nœuds de projet soient des projets de référence, d’annuaire ou de type en mode mixte, il existe un modèle d’interaction courant qui doit être appliqué comme point de départ avant de différer dans les modèles utilisateur spécifiques au projet.
Les projets doivent toujours :
Prise en charge de la possibilité d’ajouter des dossiers de projet pour organiser le contenu du projet
Conserver une consis mode tente l pour la persistance du projet
Les projets doivent également maintenir des modèles d’interaction cohérents pour :
Suppression d’éléments de projet
Enregistrement de documents
Modification des propriétés du projet
Modification du projet dans un autre affichage
Opérations glisser-déplacer
Modèle d’interaction glisser-déplacer
Les projets se classifient généralement en tant que références (en mesure de conserver uniquement les références aux éléments de projet dans le stockage), de répertoires (en mesure de conserver uniquement les éléments de projet physiquement stockés dans la hiérarchie d’un projet) ou mixtes (en mesure de conserver des références ou des éléments physiques). L’IDE accepte les trois types de projets simultanément dans le Explorateur de solutions.
Du point de vue glisser-déplacer, les caractéristiques suivantes doivent s’appliquer à chaque type de projet au sein de l’Explorateur de solutions :
Projet basé sur des références : le point clé est que le projet fait glisser autour d’une référence à un élément dans le stockage. Lorsqu’un projet basé sur des références agit comme source pour une opération de déplacement, il ne doit supprimer que la référence à l’élément du projet. L’élément ne doit pas réellement être supprimé du disque dur. Lorsqu’un projet basé sur des références agit en tant que cible pour une opération de déplacement (ou de copie), il doit ajouter une référence à l’élément source d’origine sans effectuer une copie privée de l’élément.
Projet basé sur un répertoire : à partir d’un point de glisser-déplacer, le projet fait glisser autour de l’élément physique plutôt qu’une référence. Lorsqu’un projet basé sur un répertoire agit comme source pour une opération de déplacement, il doit finir par supprimer l’élément physique du disque dur, ainsi que le supprimer du projet. Lorsqu’un projet basé sur un répertoire agit comme une cible pour une opération de déplacement (ou de copie), il doit effectuer une copie de l’élément source dans son emplacement cible.
Projet cible mixte : d’un point de vue glisser-déplacer, le comportement de ce type de projet est basé sur la nature de l’élément en cours de déplacement (référence à un élément dans le stockage ou à l’élément lui-même). Le comportement correct pour les références et les éléments physiques est décrit ci-dessus.
S’il n’y avait qu’un seul type de projet dans la Explorateur de solutions, les opérations de glisser-déplacer seraient simples. Étant donné que chaque système de projet a la possibilité de définir son propre comportement de glisser-déplacer, certaines instructions (basées sur le comportement de glisser-déplacer de l’Explorateur Windows) doivent être suivies pour garantir une expérience utilisateur prévisible :
Une opération de glisser non modifiée dans l’Explorateur de solutions (lorsque ni Ctrl ni touches Maj ne sont conservées vers le bas) doit entraîner une opération de déplacement.
L’opération de glissement de décalage doit également entraîner une opération de déplacement.
L’opération ctrl-glisser doit entraîner une opération de copie.
Les systèmes de projet basés sur des références et mixtes prennent en charge la notion d’ajout d’un lien (ou référence) à l’élément source. Lorsque ces projets sont la cible d’une opération de glisser-déplacer (lorsque Ctrl + Maj est enfoncée), il doit entraîner une référence à l’élément ajouté au projet.
Toutes les opérations de glisser-déplacer ne sont pas toutes sensibles entre les combinaisons de projets basés sur des références, basées sur des annuaires et mixtes. En particulier, il est problématique de faire semblant d’autoriser une opération de déplacement entre un projet source basé sur un répertoire et un projet cible basé sur des références, car le projet basé sur un répertoire source devra supprimer l’élément source à l’achèvement du déplacement. Le projet basé sur des références cibles se terminerait par une référence à un élément supprimé.
Il est également trompeur de prétendre autoriser une opération de copie entre ces types de projets, car le projet de référence cible ne doit pas créer une copie indépendante de l’élément source. De même, Ctrl + Maj faisant glisser vers un projet cible basé sur un répertoire ne doit pas être autorisé, car un projet basé sur un répertoire ne peut pas conserver les références. Dans les cas où l’opération glisser-déplacer n’est pas prise en charge, l’IDE doit interdire la suppression et afficher à l’utilisateur le curseur sans déplacement (illustré dans le tableau de pointeur ci-dessous).
Pour implémenter correctement le comportement de glisser-déplacer, le projet source du glisser-déplacer doit communiquer sa nature au projet cible. (Par exemple, s’agit-il d’une référence ou d’un répertoire ?) Ces informations sont indiquées par le format presse-papiers proposé par la source. En tant que source d’une opération de glisser(ou de copie du Presse-papiers), un projet doit offrir soit CF_VSREFPROJECTITEMS soit CF_VSSTGPROJECTITEMS , soit respectivement, selon que le projet est basé sur des références ou sur un répertoire. Ces deux formats ont le même contenu de données, qui est similaire au format WindowsCF_HDROP, sauf que les listes de chaînes, au lieu d’être des noms de fichiers, sont une liste de Projref chaînes à deuxNULL extrémités (comme retourné par IVsSolution::GetProjrefOfItem ou ::GetProjrefOfProject selon les besoins).
En tant que cible d’une opération de déplacement (ou de collage du Presse-papiers), un projet doit accepter les deux CF_VSREFPROJECTITEMS et CF_VSSTGPROJECTITEMS, bien que la gestion exacte de l’opération de glisser-déplacer varie en fonction de la nature du projet cible et du projet source. Le projet source déclare sa nature selon qu’il offre CF_VSREFPROJECTITEMS ou CF_VSSTGPROJECTITEMS. La cible de la suppression comprend sa propre nature et dispose donc de suffisamment d’informations pour prendre des décisions quant à l’exécution d’un déplacement, d’une copie ou d’un lien. L’utilisateur modifie également l’opération de glisser-déplacer qui doit être effectuée en appuyant sur Ctrl, Maj ou les touches Ctrl et Maj. Il est important que la cible de suppression indique correctement quelle opération sera effectuée à l’avance dans ses DragEnter méthodes.DragOver Le Explorateur de solutions sait automatiquement si le projet source et le projet cible sont le même projet.
Le fait de faire glisser des éléments de projet entre des instances de Visual Studio (par exemple, d’une instance devenv.exe à une autre) n’est spécifiquement pas pris en charge. Le Explorateur de solutions désactive également cela directement.
L’utilisateur doit toujours être en mesure de déterminer l’effet d’une opération de glisser-déplacer en sélectionnant un élément, en le faisant glisser vers l’emplacement cible et en observant lequel des pointeurs de souris suivants s’affiche avant la suppression de l’élément :
| Mouse pointer | Commande | Description |
|---|---|---|
 |
Aucune suppression | Impossible de supprimer l’élément à l’emplacement spécifié. |
 |
Copier | L’élément est copié à l’emplacement cible. |
 |
Poursuivre | L’élément est déplacé vers l’emplacement cible. |
 |
Ajouter la référence | Une référence à l’élément sélectionné sera ajoutée à l’emplacement cible. |
Projets basés sur des références
Le tableau suivant récapitule les opérations glisser-déplacer (ainsi que couper/copier/coller) qui doivent être effectuées en fonction de la nature de l’élément source et des touches de modificateur enfoncées pour les projets cibles référencés :
| Modificateur | Catégorie | Élément source : Référence/Lien | Élément source : élément physique ou système de fichiers (CF_HDROP) |
|---|---|---|---|
| Aucun modificateur | Action | Poursuivre | Lien |
| Aucun modificateur | Cible | Ajoute une référence à l’élément d’origine | Ajoute une référence à l’élément d’origine |
| Aucun modificateur | Source | Supprime la référence à l’élément d’origine | Conserve l’élément d’origine |
| Aucun modificateur | Résultats | DROPEFFECT_MOVE est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_LINK est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
| Maj+Glisser | Action | Poursuivre | Aucune suppression |
| Maj+Glisser | Cible | Ajoute une référence à l’élément d’origine | Aucune suppression |
| Maj+Glisser | Source | Supprime la référence à l’élément d’origine | Aucune suppression |
| Maj+Glisser | Résultats | DROPEFFECT_MOVE est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
Aucune suppression |
| Ctrl+Glisser | Action | Copier | Aucune suppression |
| Ctrl+Glisser | Cible | Ajoute une référence à l’élément d’origine | Aucune suppression |
| Ctrl+Glisser | Source | Conserve la référence à l’élément d’origine | Aucune suppression |
| Ctrl+Glisser | Résultats | DROPEFFECT_COPY est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
Aucune suppression |
| Ctrl+Maj+Glisser | Action | Lien | Lien |
| Ctrl+Maj+Glisser | Cible | Ajoute une référence à l’élément d’origine | Ajoute une référence à l’élément d’origine |
| Ctrl+Maj+Glisser | Source | Conserve la référence à l’élément d’origine | Conserve l’élément d’origine |
| Ctrl+Maj+Glisser | Résultats | DROPEFFECT_LINK est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_LINK est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
| Ctrl+Maj+Glisser | Remarque | Identique au comportement de glisser-déplacer pour les raccourcis dans l’Explorateur Windows. | |
| Couper/coller | Action | Poursuivre | Lien |
| Couper/coller | Cible | Ajoute une référence à l’élément d’origine | Ajoute une référence à l’élément d’origine |
| Couper/coller | Source | Conserve la référence à l’élément d’origine | Conserve l’élément d’origine |
| Couper/coller | Résultats | L’élément reste à l’emplacement d’origine dans le stockage | L’élément reste à l’emplacement d’origine dans le stockage |
| Copier/coller | Action | Copier | Lien |
| Copier/coller | Source | Ajoute une référence à l’élément d’origine | Ajoute une référence à l’élément d’origine |
| Copier/coller | Résultats | Conserve la référence à l’élément d’origine | Conserve l’élément d’origine |
| Copier/coller | Action | L’élément reste à l’emplacement d’origine dans le stockage | L’élément reste à l’emplacement d’origine dans le stockage |
Projets basés sur des annuaires
Le tableau suivant récapitule les opérations glisser-déplacer (ainsi que couper/copier/coller) qui doivent être effectuées en fonction de la nature de l’élément source et des touches de modificateur enfoncées pour les projets cibles basés sur un répertoire :
| Modificateur | Catégorie | Élément source : Référence/Lien | Élément source : élément physique ou système de fichiers (CF_HDROP) |
|---|---|---|---|
| Aucun modificateur | Action | Poursuivre | Poursuivre |
| Aucun modificateur | Cible | Copie l’élément à l’emplacement cible | Copie l’élément à l’emplacement cible |
| Aucun modificateur | Source | Supprime la référence à l’élément d’origine | Supprime la référence à l’élément d’origine |
| Maj+Glisser | Action | Poursuivre | Poursuivre |
| Maj+Glisser | Cible | Copie l’élément à l’emplacement cible | Copie l’élément à l’emplacement cible |
| Maj+Glisser | Source | Supprime la référence à l’élément d’origine | Supprime l’élément de l’emplacement d’origine |
| Maj+Glisser | Résultats | DROPEFFECT_MOVE est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_MOVE est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
| Ctrl+Glisser | Action | Copier | Copier |
| Ctrl+Glisser | Cible | Copie l’élément à l’emplacement cible | Copie l’élément à l’emplacement cible |
| Ctrl+Glisser | Source | Conserve la référence à l’élément d’origine | Conserve la référence à l’élément d’origine |
| Ctrl+Glisser | Résultats | DROPEFFECT_COPY est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_COPY est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
| Ctrl+Maj+Glisser | Aucune suppression | Aucune suppression | |
| Couper/coller | Action | Poursuivre | Poursuivre |
| Couper/coller | Cible | Copie l’élément à l’emplacement cible | Copie l’élément à l’emplacement cible |
| Couper/coller | Source | Supprime la référence à l’élément d’origine | Supprime l’élément de l’emplacement d’origine |
| Couper/coller | Résultats | L’élément reste à l’emplacement d’origine dans le stockage | L’élément est supprimé de l’emplacement d’origine dans le stockage |
| Copier/coller | Action | Copier | Copier |
| Copier/coller | Cible | Ajoute une référence à l’élément d’origine | Copie l’élément à l’emplacement cible |
| Copier/coller | Source | Conserve l’élément d’origine | Conserve l’élément d’origine |
| Copier/coller | Résultats | L’élément reste à l’emplacement d’origine dans le stockage | L’élément reste dans un emplacement d’origine dans le stockage |
Projets cibles mixtes
Le tableau suivant récapitule les opérations glisser-déplacer (ainsi que couper/copier/coller) qui doivent être effectuées en fonction de la nature de l’élément source et des touches de modificateur enfoncées pour les projets à cible mixte :
| Modificateur | Catégorie | Élément source : Référence/Lien | Élément source : élément physique ou système de fichiers (CF_HDROP) |
|---|---|---|---|
| Aucun modificateur | Action | Poursuivre | Poursuivre |
| Aucun modificateur | Cible | Ajoute une référence à l’élément d’origine | Copie l’élément à l’emplacement cible |
| Aucun modificateur | Source | Supprime la référence à l’élément d’origine | Supprime la référence à l’élément d’origine |
| Aucun modificateur | Résultats | DROPEFFECT_ MOVE est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_ MOVE est retourné en tant qu’action depuis ::Drop et l’élément est supprimé de l’emplacement d’origine dans le stockage |
| Maj+Glisser | Action | Poursuivre | Poursuivre |
| Maj+Glisser | Cible | Ajoute une référence à l’élément d’origine | Copie l’élément à l’emplacement cible |
| Maj+Glisser | Source | Supprime la référence à l’élément d’origine | Supprime l’élément de l’emplacement d’origine |
| Maj+Glisser | Résultats | DROPEFFECT_ MOVE est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_ MOVE est retourné en tant qu’action depuis ::Drop et l’élément est supprimé de l’emplacement d’origine dans le stockage |
| Ctrl+Glisser | Action | Copier | Copier |
| Ctrl+Glisser | Cible | Ajoute une référence à l’élément d’origine | Copie l’élément à l’emplacement cible |
| Ctrl+Glisser | Source | Conserve la référence à l’élément d’origine | Conserve l’élément d’origine |
| Ctrl+Glisser | Résultats | DROPEFFECT_ COPY est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_ COPY est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
| Ctrl+Maj+Glisser | Action | Lien | Lien |
| Ctrl+Maj+Glisser | Cible | Ajoute une référence à l’élément d’origine | Ajoute une référence à l’élément source d’origine |
| Ctrl+Maj+Glisser | Source | Conserve la référence à l’élément d’origine | Conserve l’élément d’origine |
| Ctrl+Maj+Glisser | Résultats | DROPEFFECT_ LINK est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
DROPEFFECT_ LINK est retourné en tant qu’action depuis et l’élément reste à l’emplacement ::Drop d’origine dans le stockage |
| Couper/coller | Action | Poursuivre | Poursuivre |
| Couper/coller | Cible | Copie l’élément à l’emplacement cible | Copie l’élément à l’emplacement cible |
| Couper/coller | Source | Supprime la référence à l’élément d’origine | Supprime l’élément de l’emplacement d’origine |
| Couper/coller | Résultats | L’élément reste à l’emplacement d’origine dans le stockage | L’élément est supprimé de l’emplacement d’origine dans le stockage |
| Copier/coller | Action | Copier | Copier |
| Copier/coller | Cible | Ajoute une référence à l’élément d’origine | Copie l’élément à l’emplacement cible |
| Copier/coller | Source | Conserve l’élément d’origine | Conserve l’élément d’origine |
| Copier/coller | Résultats | L’élément reste à l’emplacement d’origine dans le stockage | L’élément reste à l’emplacement d’origine dans le stockage |
Ces détails doivent être pris en compte lors de l’implémentation du glissement dans la Explorateur de solutions :
Conception pour plusieurs scénarios de sélection.
Les noms de fichiers (chemin d’accès complet) doivent être uniques dans le projet cible ou la suppression ne doit pas être autorisée.
Les noms de dossiers doivent être uniques (sans respect de la casse) au niveau qu’ils sont supprimés.
Il existe des différences de comportement entre les fichiers ouverts ou fermés au moment du glissement (non mentionnés dans les scénarios ci-dessus).
Les fichiers de niveau supérieur se comportent légèrement différemment des fichiers dans les dossiers.
Un autre problème à prendre en compte est la façon de gérer les opérations de déplacement sur les éléments qui ont des concepteurs ou éditeurs ouverts. Le comportement attendu est le suivant (cela s’applique à tous les types de projets) :
Si l’éditeur/concepteur ouvert n’a pas de modifications non enregistrées, la fenêtre éditeur/concepteur doit être fermée en mode silencieux.
Si l’éditeur/concepteur ouvert n’a pas de modifications enregistrées, la source du glisser-déplacer doit attendre la suppression, puis demander à l’utilisateur d’enregistrer les modifications non validées dans les documents ouverts avant de fermer la fenêtre avec une invite similaire à ce qui suit :
========================================================== One or more open documents have unsaved changes. Do you want to save uncommitted changes before proceeding? [Yes] [No] [Cancel] ==========================================================
Cela permet à l’utilisateur d’enregistrer le travail en cours avant que la cible n’effectue ses copies. Une nouvelle méthode IVsHierarchyDropDataSource2::OnBeforeDropNotify a été ajoutée pour activer cette gestion.
La cible copie ensuite l’état de l’élément tel qu’il se trouve dans le stockage (sans inclure les modifications non enregistrées dans l’éditeur si l’utilisateur a choisi Non). Une fois que la cible a terminé sa copie (in IVsHierarchyDropDataSource::Drop), la source a la possibilité de terminer la partie de suppression de l’opération de déplacement (en IVsHierarchyDropDataSource::OnDropNotify).
Tous les éditeurs avec des modifications non enregistrées doivent être laissés ouverts. Pour ces documents avec des modifications non enregistrées, cela signifie que la partie de copie de l’opération de déplacement est effectuée, mais que la partie supprimer est abandonnée. Dans un scénario de sélection multiple lorsque l’utilisateur choisit Non, ces documents avec des modifications non enregistrées ne doivent pas être fermés ou supprimés, mais ceux sans modifications non enregistrées doivent être fermés et supprimés.