Dépannage du développement au moment du design
Les problèmes courants suivants peuvent se produire lorsque vous créez une expérience personnalisée au moment du design pour vos composants et contrôles Windows Forms :
Impossible de compiler
Impossible de déboguer au moment du design
Erreur de compilation : « Le type ou nom de l'espace de noms 'nom de type' est introuvable. »
Erreur au moment du design : « Échec lors de la création du composant 'nom de composant'. »
Erreur de débogage : « Opération inter-threads non conforme : Contrôle 'nom de contrôle' accessible à partir d'un thread autre que le thread sur lequel il a été créé. »
Erreur au moment du design : « Impossible d'ouvrir un concepteur pour ce fichier, car la classe qu'il contient n'hérite pas d'une classe qui peut être conçue visuellement. »
Les glyphes sont conservés après la suppression du composant
Comportement du concepteur par défaut masqué par le comportement personnalisé
Événements de concepteur déclenchés de manière involontaire
Échec de la sérialisation des collections
Le concepteur n'acquiert pas de référence UndoEngine
L'environnement de design ne reconnaît pas les modifications apportées aux propriétés du composant
Syntaxe DesignerAttribute
Actualisation de l'environnement de design après avoir apporté des modifications au composant ou au concepteur
Avertissement FxCop sur le nouveau Windows Form généré : DoNotInitializeUnnecessarily
Classes partielles et Concepteur Windows Forms
Les contrôles personnalisés hérités provoquent un comportement inattendu dans le concepteur
La balise active d'un concepteur hébergé lève une exception
L'icône du composant n'apparaît pas dans la boîte à outils
Impossible de compiler
Pour une part importante du développement au moment du design, vous devez ajouter une référence à l'assembly au moment du design, System.Design.dll. Cet assembly n'est pas inclus dans le Framework 4 Client Profile. Pour ajouter une référence à System.Design.dll, vous devez remplacer le Framework cible du projet par .NET Framework 4.
Impossible de déboguer au moment du design
Pour déboguer votre code au moment du design, deux méthodes s'offrent à vous :
Placez les appels MessageBox.Show à des points stratégiques dans votre code.
Attachez une autre instance de Visual Studio pour déboguer l'environnement de design de la première instance.
Pour plus d'informations, consultez Comment : accéder aux services au moment du design.
Erreur de compilation : « Le type ou nom de l'espace de noms 'nom de type' est introuvable »
Vous devez référencer l'assembly System.Design. Les types liés au concepteur se trouvent dans l'assembly System.Design. Il comprend les types des espaces de noms System.Windows.Forms.Design et System.ComponentModel.Design.
Veillez également à importer les espaces de noms dont vous avez besoin à l'aide des mots clés Imports ou using. Pour plus d'informations, consultez Comment : accéder à la prise en charge au moment du design dans les Windows Forms.
Erreur au moment du design : « Échec lors de la création du composant 'nom de composant' »
Vous pouvez recevoir cette erreur de la Boîte à outils lorsque vous créez votre composant ou votre contrôle sur l'aire de conception. Le tableau suivant présente les deux causes possibles de cette erreur.
Cause |
Description |
Remarques |
|---|---|---|
Constructeur par défaut manquant |
Votre composant ou contrôle doit posséder un constructeur par défaut qui est un constructeur sans paramètre. |
L'environnement de design requiert un constructeur par défaut pour pouvoir créer une instance de votre type. |
Le composant est un type générique |
Votre composant ou contrôle ne peut pas être un type générique, également appelé un type de modèle ou un type paramétré. L'environnement de design ne prend pas en charge les types génériques. |
Si votre type générique dérive de UserControl et que vous tentez de l'exécuter dans le conteneur de test UserControl de Visual Studio, vous recevrez l'erreur suivante : Échec lors de la création du contrôle UserControl 'nom' Le message d'erreur était « Impossible de créer un type pour lequel Type.ContainsGenericParameters est true ». UserControl sera supprimé de la liste. Bien que vos composants et contrôles ne puissent pas être des types génériques, ils peuvent utiliser des types génériques. |
Erreur au moment du design : « La valeur ne peut pas être nulle.Nom du paramètre : 'nom de composant' »
Vous pouvez recevoir cette erreur de la Boîte à outils lorsque vous créez votre composant ou votre contrôle sur l'aire de conception. La cause la plus probable est que vous essayez d'utiliser un composant ou un contrôle qui a été construit pour un assembly 64 bits. L'environnement de design Visual Studio ne prend pas en charge les composants 64 bits.
Erreur de débogage : « Opération inter-threads non conforme : Contrôle 'nom de contrôle' accessible à partir d'un thread autre que le thread sur lequel il a été créé. »
Si vous utilisez le multithreading dans vos applications Windows Forms, vous devez veiller à effectuer des appels à vos contrôles de façon thread-safe. Cette exception est levée par le débogueur et n'apparaît pas au moment de l'exécution, mais il est fortement recommandé de régler ce problème lorsque vous le remarquez. Pour plus d'informations, consultez Comment : faire des appels thread-safe aux contrôles Windows Forms.
Erreur au moment du design : « Impossible d'ouvrir un concepteur pour ce fichier, car la classe qu'il contient n'hérite pas d'une classe qui peut être conçue visuellement »
Le fichier comprenant votre composant ou contrôle peut contenir plusieurs définitions de classe mais la première classe dans le fichier doit être une classe que vous pouvez concevoir. La première classe dans le fichier doit implémenter l'interface IComponent ou bien elle doit dériver de la classe Component ou d'une classe qui dérive Component.
Les glyphes sont conservés après la suppression du composant
Si votre concepteur personnalisé crée des objets Adorner, vous devez les supprimer de l'aire de conception lorsque votre concepteur passe hors de portée. Appelez BehaviorServiceAdornerCollection.Remove dans la méthode Dispose de votre concepteur afin d'effacer les objets Glyph ainsi que les objets Adorner et Behavior liés. Pour plus d'informations, consultez Comment : étendre l'apparence et le comportement des contrôles en mode design.
Comportement du concepteur par défaut masqué par le comportement personnalisé
Le Concepteur de contrôles par défaut crée un glyphe qui couvre le contrôle entier sur l'aire de conception. Il est appelé glyphe de corps. Si votre Concepteur de contrôles personnalisé crée un glyphe avec les mêmes limites que le glyphe de corps, il masquera l'implémentation Behavior sous-jacente associée au glyphe de corps. Cela empêche l'apparition des fonctionnalités par défaut telles que les balises actives et les glyphes de redimensionnement.
Vous ne pouvez pas passer de messages parmi les objets Behavior si bien que vous ne pouvez pas gérer un message de la souris et l'envoyer à des objets Behavior sous-jacents. Lorsque vous implémentez un glyphe qui couvre le contrôle entier, vous êtes responsable de l'apparence et du comportement entiers de votre expérience de design personnalisée.
Événements de concepteur déclenchés de manière involontaire
Si votre concepteur personnalisé attache des gestionnaires d'événements aux événements de concepteur tels que ComponentRemoved ActiveDesignerChanged et SelectionChanged, vous devez détacher vos gestionnaires d'événements dans la méthode Dispose de votre concepteur.
Si vous ne le faites pas, cela peut entraîner un comportement involontaire au moment du design. La liste suivante présente certains symptômes qui peuvent apparaître :
Boîte de message d'erreur : « Une erreur s'est produite pendant le traitement de cette commande. »
Boîte de message d'erreur : « La référence d'objet n'a pas la valeur de l'instance d'un objet. »
Les gestionnaires d'événements sont appelés de façon inappropriée lors de la suppression des composants ou lors de la fermeture des concepteurs.
Échec de la sérialisation des collections
Si vous souhaitez que la propriété de collection de votre composant ou contrôle personnalisé soit sérialisée, appliquez DesignerSerializationVisibilityAttribute et affectez-lui la valeur Content. Pour plus d'informations, consultez Comment : sérialiser des collections de types standard avec DesignerSerializationVisibilityAttribute.
Le concepteur n'acquiert pas de référence UndoEngine
Si vous tentez d'acquérir une référence au service UndoEngine au cours du chargement d'un formulaire, la méthode GetService retourne null.
Le service UndoEngine n'est ni créé ni activé tant que la phase de chargement du formulaire n'est pas terminée. Une fois que le formulaire est chargé, les appels suivants à GetService retourneront une référence UndoEngine.
En général, vous devez rarement demander une référence directement à UndoEngine. Les cas dans lesquels cela est nécessaire sont généralement provoqués par l'action d'un utilisateur et se produisent après le chargement du concepteur.
L'environnement de design ne reconnaît pas les modifications apportées aux propriétés du composant
L'environnement de design ne reconnaît pas les modifications apportées à votre composant ou contrôle si vous définissez directement les propriétés. Pour que les événements tels que ComponentChanged soient déclenchés, vous devez définir la valeur des propriétés de votre composant avec la méthode PropertyDescriptor.SetValue. Ainsi; l'environnement de design est averti de la modification de la propriété, permettant la mise à jour correcte de l'aire de conception et des contrôles PropertyGrid. Pour plus d'informations, consultez Comment : étendre l'apparence et le comportement des contrôles en mode design.
Syntaxe DesignerAttribute
Vous attachez votre concepteur personnalisé au contrôle qu'il conçoit en appliquant DesignerAttribute au contrôle.
Vous devez spécifier les paramètres DesignerAttribute avec précision ; sinon, l'environnement de design ne chargera pas votre concepteur personnalisé.
Actualisation de l'environnement de design après avoir apporté des modifications au composant ou au concepteur
Lorsque vous apportez des modifications aux aspects liés à la conception d'un composant, vous devez générer à nouveau le projet du composant. De plus, si un autre projet Windows Forms est actuellement ouvert et utilise ce composant, vous devrez probablement actualiser le projet pour consulter les modifications. En général, vous devez fermer et rouvrir la fenêtre de conception contenant le composant.
Avertissement FxCop sur le nouveau Windows Form généré : DoNotInitializeUnnecessarily
Le Concepteur Windows Forms génère le code suivant pour les projets d'application Windows Forms en C#.
private System.ComponentModel.IContainer components = null;
Selon les règles FxCop qui sont appliquées, FxCop peut produire l'avertissement « DoNotInitializeUnnecessarily ». Cela est dû au fait que null est le Common Language Runtime (CLR) par défaut pour les propriétés de référence.
Si le concepteur n'a pas initialisé le champ components à la valeur null, le compilateur C# produit l'avertissement suivant :
« Form1.components n'est jamais assigné et possédera toujours sa valeur par défaut nulle. »
Vous pouvez supprimer l'avertissement FxCop avec SuppressMessageAttribute mais cela peut entraîner des problèmes de maintenance si le nom de classe est modifié. Il est donc recommandé d'ignorer l'avertissement FxCop.
Classes partielles et Concepteur Windows Forms
Par défaut, le Concepteur Windows Forms émet le code de sérialisation du concepteur dans un fichier dédié distinct du fichier principal de votre composant. Par exemple, dans un projet d'application Windows Forms, la définition de la classe Form1 est divisée en deux fichiers, comme indiqué dans le tableau suivant.
Fichier (noms de fichier C#) |
Fonction |
|---|---|
Form1.cs |
Fichier de classe principale |
Form1.Designer.cs |
Code émis par le concepteur |
Fichier (noms de fichier VB) |
Fonction |
|---|---|
Form1.vb |
Fichier de classe principale |
Form1.Designer.vb |
Code émis par le concepteur |
En général, il n'est pas nécessaire de modifier le code émis par le Concepteur Windows Forms. À la place, modifiez le fichier de classe principal.
Le Concepteur Windows Forms utilise le mot clé partial pour diviser l'implémentation de Form1 en deux fichiers séparés. Cela évite au code émis par le concepteur d'être entrecoupé par votre code. Pour plus d'informations sur le mot clé partial, consultez Classes et méthodes partielles (Guide de programmation C#) et Partial (Visual Basic).
Le Concepteur Windows Forms ne prend pas en charge la division d'une définition de type concevable en plus de deux implémentations partial. Cette restriction inclut la création d'un nouveau fichier de classe contenant une troisième définition partielle du type, ainsi que l'ajout d'une troisième définition de classe partielle du type dans le fichier principal ou le fichier de concepteur. Les membres définis de cette façon ne seront pas visibles dans le Concepteur Windows Forms.
Les contrôles personnalisés hérités provoquent un comportement inattendu dans le concepteur
Lorsque des types sont invalidés dans le concepteur, ComponentSerializationService exécute un rechargement partiel pour actualiser le concepteur avec les types mis à jour. Les versions de Visual Studio précédant Visual Studio 2005 ont complètement rechargé le concepteur. Le comportement de rechargement partiel dans Visual Studio 2005 est plus rapide qu'un rechargement complet et conserve également la pile d'annulation.
Il se peut que les composants et les sérialiseurs correspondants créés avant Visual Studio 2005 ne soient pas à même de s'adapter à un rechargement partiel. Les composants et les contrôles peuvent provoquer un comportement inattendu, car ils ont été créés pour une désérialisation uniquement au cours d'un rechargement complet. Les symptômes incluent des dépassements de capacité de la pile, des blocages ou des régions vides dans le concepteur Windows Forms lorsque des contrôles hérités sont présents.
Vous pouvez rétablir le comportement de rechargement complet en ajoutant le paramètre suivant au fichier devenv.exe.config. Si vous avez installé Visual Studio 2005 à l'emplacement par défaut, ce fichier se trouve dans le dossier C:\Program Files\Microsoft Visual Studio 8\Common7\IDE.
<appSettings>
<add key="EnableOptimizedDesignerReloading" value="false" />
</appSettings>
La balise active d'un concepteur hébergé lève une exception
Si vous hébergez un concepteur en dehors de Visual Studio, vos balises actives peuvent lever une NullReferenceException. Pour résoudre ce problème, fournissez une référence IUIService dans votre concepteur et implémentez la propriété Styles. Dans le IDictionary exposé par Styles, assignez un nouveau Font comme élément spécifié par la clé « DialogFont », comme indiqué dans le fragment de code suivant.
Styles["DialogFont"] = new Font(...);
L'icône du composant n'apparaît pas dans la boîte à outils
Dans Visual Studio, lorsque vous utilisez ToolboxBitmapAttribute pour associer une icône à votre composant personnalisé, le bitmap n'apparaît pas dans la Boîte à outils des composants générés automatiquement. Pour afficher la bitmap, rechargez le contrôle à l'aide de la boîte de dialogue Choisir des éléments de boîte à outils. Pour plus d'informations, consultez Toolbox Icons.
Voir aussi
Tâches
Comment : accéder aux services au moment du design
Concepts
Erreurs au moment du design dans le Concepteur Windows Forms