Component perso qui disparait du formulaire

Bonjour !
Je m'attaque en ce moment à comprendre comment créer des contrôles et composants et j'ai un problème avec un composant.

Ce composant n'a pas d'interface graphique, donc j'ai bien compris que je devais utiliser une classe héritant de "Component" pour qu'il se retrouve dans la zone prévue à cet effet quand je glisse mon composant sur le formulaire.

Tout fonctionne à merveille excepté une chose. Si je ferme le designer et que je ré-ouvre mon formulaire en mode design, mon composant a disparu. Pire encore, ce composant est en fait destiné à être attribué à une propriété de contrôles personalisés, et même si mon composant était bien attribué, quand je réouvre mon formulaire, cette propriété a été réinitialisée ! (logique j'imagine vu que le composant n'existe plus).

Pour être sûr de la disparition de mon composant, j'ai essayé de voir dans l'onglet "Structure du document" et dans le designer de mon formulaire, mais il a bien disparu :calim2:

Durant mes lectures de tutos, j'ai entendu parler de "persistence" et de "sérialisation". Mon problème pourrait-i venir de là ? J'ai essayé de mettre l'attribut <Serializable()> _ sur mon composant, mais rien n'y change.

Quelle pourrait être la cause de ce problème ? Est-ce un problème souvent rencontré par les newbies comme moi ? Est-ce un problème tout bête auquel il faut penser à chaque fois qu'on créé un composant ?

Mon code est un peu long à mettre ici, mais je peux évidemment le fournir.
Merci d'avance pour vos idées.

Salut,
Il s'agit effectivement d'un problème de sérialisation, du moins a priori.
Cependant, il ne s'agit pas de l'attribut Serializable. Celui-ci est utilisé pour faire de la sérialisation d'une instance vers un fichier ou un stream à des fins de persistance ou de communication réseau (soap, remoting, ...)

Pour toi il s'agit d'une sérialisation pour le Designer de Visual Studio, et ca se passe ici : http://msdn.microsoft.com/fr-fr/library/ms171834.aspx

Salut ctxnop et merci pour ton aide.
Ton lien est intéressant malgré le fait que je n'y comprenne pas grand chose.

Comme ce n'est pas la première fois qu'il m'arrive des choses étranges après de multiples générations d'une libraire, j'ai essayer de recréer un projet vide avec un composant très simple, et là, surprise, quand je ferme le designer et que je le recharge, mon composant reste bien à sa place. 8O

En relisant ton lien, je pense en ressortir deux règles principales qui pourraient éventuellement être en relation avec mon soucis, mais sans en être sûr.

Citation:

---

Lorsque vous placez un contrôle Button sur un formulaire dans un concepteur et que vous affichez le code généré, vous découvrez qu'un seul sous-ensemble de propriétés est persistant dans le code.En général, il s'agit des propriétés pour lesquelles vous avez explicitement défini une valeur.

---

et ...

Citation:

---

Si le type ne peut pas être converti en chaîne mais qu'il est public et possède un constructeur vide, le ObjectXmlSerializer sera utilisé.

---

En général, pour un composant ou une classe, je créé mes membres et leur attribue une valeur par défaut directement (pas dans le constructeur), sauf pour les membres "complexes" (classes persos) auquels j'attribue la valeur par défaut dans le constructeur.

Le problème pourrait venir de là si je suis obligé d'avoir un constructeur vide ?

Le pire c'est que dans un nouveau projet, ça a l'air de marcher sans que je n'ai rien à faire, alors que dans mon vieux projet, mon composant disparait à tous les coups.

Il y a peut être moyen de faire un composant sans constructeur par défaut, mais pas a ma connaissance.
De façon générale :
- Un composant (ou contrôle) doit avoir un constructeur sans paramètre pour être instanciable par le designer.
- Le composant (ou contrôle) doit être entièrement paramétrable à coup de propriété (ca veut dire qu'il faut oublier le coup classique de la méthode d'initialisation)
- Il faut poser les bons attributs sur les propriétés. Ces attributs servent à renseigner la grille de propriété du Designer, mais pas seulement. Ca sert également à indiquer les propriété dont la valeur est sérialisée systématiquement ou si la valeur n'est sérialisée que si elle est différente de la valeur par défaut. Ca sert aussi à définir un éditeur de pour le Designer (par exemple, une fenêtre d'ajout d'élément dans une collection)

Tout ceci est sérialisé dans la méthode "InitializeComponent" générée par le Designer, en conséquence c'est plutôt sensible, si un truc part de travers le Designer crash. Il est donc souvent préférable de les isoler au maximum pendant leurs développement.

Okiii je commence à mieux comprendre tout ce bazard que VisualStudio planque dans le designer en recoupant tes explications et toutes mes lectures :ccool:

Pour ce qui est du constructeur sans paramètres je le comprend aisément, quoique ce soit à moitié vrai, exemple justement, les contrôles destinés à être utilisés par un UITypeEditor (j'apprends ça aussi en même temps).
Par contre, je ne comprends pas en quoi ça gène de régler toutes les propriétés d'un contrôle dans son constructeur... tout en le laissant sans paramètres bien sûr).
Perso j'ai toujours plein de trucs à exécuter quand j'instancie un contrôle, mais c'est vrai que je n'ai jamais chercher le meilleur moyen de le faire, et c'était souvent pour de simples classes.

exemple 1 rien dans le constructeur:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Public Class Machin Inherits Control   private _Color As Color = Color.White   Public Property Color() As Color Get Return _Color End Get Set(ByVal value As Color) _Color = value End Set End Property   Public Sub New() End Sub   End Class

---

là pas de soucis, ça marche ... pour un type perso en tant que propriété aussi. Autant c'est propre pour un type simple, mais pour un type compliqué je trouve ça plus pratique de juste déclarer la variable "en haut" et l'instancier dans le constructeur ou une méthode d'initialisation apellée dans le constructeur.

En tous cas, je pense effectivement que j'avais foutu le bazard dans mon projet et que le designer plantait à cause de ça.

Merci beaucoup pour ton aide ;)

Les contrôles destiné à être utilisé via un UITypeEditor ca n'a pas grand chose à voir.
Encore que les règles que j'ai énoncées plus haut restent vrais.

Il faut bien comprendre qu'un contrôle ce n'est absolument rien d'autre qu'une classe normale. Il y a de l'héritage, du polymorphisme, etc...
Et surtout : les utilisateurs de la classe.

Le Designer est un utilisateur de classes qui héritent de Component ( et donc aussi de Control puisque celui-ci hérite de Component).
La manière dont lui l'utilise est simple : il instancie la classe en utilisant le constructeur par défaut, il place l'instance de la classe dans la grille de propriété. Cette grille permet de modifier une à une les propriétés de l'instance. Mais elle ne permet pas d'appeler une méthode initialize qui prendrait en paramètre toutes les propriétés de l'objet. Enfin, le Designer sérialise l'objet sous forme de code C# ou VB.Net qu'il place ensuite dans la méthode InitializeComponent (méthode généralement placée dans le fichier .Designer.cs/vb)

Le code généré est donc une sérialisation de l'objet. Par défaut, cette sérialisation est simple :
- instanciation de l'objet via le constructeur par défaut de sa classe
- Pour chaque propriété publique de la classe on génère une ligne d'affectation de cette propriété (sauf si la valeur de l'instance gérée par le designer est égale à la valeur par défaut).

Voilà, c'est tout.

Ca ne veux pas dire qu'un contrôle ne peut pas avoir AUSSI des constructeurs plus complexes et/ou des méthodes d'initialisation. Simplement ils ne seront pas utilisé par le design.

En conséquence, rien ne t'empêche de créer un contrôle qui ne suis pas ces règles, mais dans ce cas le Designer sera incapable de s'en servir convenablement. Cependant, le contrôle fonctionnera parfaitement dans le cas d'une utilisation "à la main" (c'est à dire quand c'est toi qui tape le code qui instancie, place et paramètre le contrôle).

Et c'est exactement ce que tu fais dans le cadre des UITypeEditor. La méthode EditValue de cette classe est à surcharger pour placer le code qui modifie la valeur d'une propriété d'un contrôle.
Et ce code c'est toi qui le tape. En conséquence tu peux faire ce que tu veux, comme instancier un contrôle en passant directement la valeur dans le constructeur, ou même générer une valeur par code sans passer par une interface graphique. Ici, l'utilisateur de la classe n'est pas le Designer, ou la grille de propriété ou même le UITypeEditor, mais toi.