[usercontrol] Propriété de type dictionary non serialisable --> error au design à l'utilisation

Hello,

Apparemment, si on met une propriété P de type Dictionary dans un UC (usercontrol), si on change une propriété (une autre!!) de ce UC dans un projet qui l'utilise pendant le design, on obtient une erreur lors de la prochaine tentative de build disant que la génération du code pour la propriété P a échouté car ce n'est pas serialisable...

Ci-dessous, le message complet :

Citation:

Code generation for property 'xxxxx' failde. Error was: 'Type 'System.Windows.Forms.UserControl' in Assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.'

Vu que la propriété en question est de type Dictionary et que qu'un dictionnaire n'est pas sérialisable, j'en déduis que le problème est là.

Que faire du coup ? Quelqu'un aurait une idée ?

Et si ce n'est pas clair, faut le dire aussi.

Maintenant que la question est posée, je vais fouiller la toile.

C'est résolu mais j'aimerais qu'on m'explique

Hello,

En fouillant et en y allant à tâtons, j'ai résolu le problème en ajoutant l'attribut <DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> à la propriété fautive.

Le designer ne râle plus. Ce qui est logique puisque vu le nom de l'attribut, on peut s'attendre à ce que cette propriété lui soit masquée pour la sérialisation et donc il ne butte plus dessus.

Quelqu'un aurait un lien sur le fonctionnement du designer ? J'aimerais comprendre ce qu'il se trame en arrière-plan...

"sérialisation" du designer windows forms :
il traduit toute l'interface en ligne de code vb.net, dans le fichier .designer.vb

quand tu poses un bouton sur l'interface il ajoute la ligne qui déclare la variable, la ligne qui fait le new, la ligne qui fait le .controls.add(lebouton) et une ligne par propriété ayant une valeur différente de la valeur par défaut (pour ne pas avoir trop de code les valeurs avec la valeur par défaut ne sont pas mises)
la valeur par défaut c'est un attribut aussi (presque tous les attributs utiles au designer windows forms sont dans system.componentmodel)
aussi on peut définir une valeur par défaut quand on sort du cadre des valeurs par défaut du compilateur (integer à 0 par exemple) ca doit être utile donc quand on met une valeur par défaut dans la variable privée

pour les types par valeur (int date et autre struct) une propriété = une ligne de code avec la valeur
pour les types par référence (classes) c'est une instance qui est enregistrée (donc new de la classe, remplissage de ses propriétés puis set de cette instance dans la propriété du controle)

quand c'est des grandes instances, celles ci sont sérialisées (en machin 64 je dirais) dans le fichier .resx et la ligne de code correspondante est un accès à ce fichier (.GetRessource ou un truc dans le genre)

si ton dictionnaire contient des controles, il va donc essayer de sérialiser tout ca, et la classe control n'est pas sérialisable (dictionary l'est)

après il y a donc l'attribut designerserialisationvisibility qui peut aider, on peut lui dire qu'il n'enregistre rien (hidden) et après il y a visible et content
ca fait longtemps que je ne l'ai pas utilisé donc je ne sais plus exactement ce que ca fait, mais dans un cas il enregistre les lignes de code pour créer l'instance, et dans l'autre cas juste le pointeur

après il y a encore des tas de choses à savoir sur le designer WinForm et ce qu'il fait
pour en avoir une idée tu peux regarder ce qu'il y a comme attributs et interfaces dans componentmodel (tout ne s'y réfère pas)
il y a aussi des interfaces prises en compte comme une interface d'initilisation, si le designer voit que ton controle la gère il appelera beginedit et endedit, te permettant de ne pas exécuter du code quand ce n'est pas utile, certains controles du framework l'implémentent

un truc pratique par contre, quand on met une propriété as button par exemple (as un control en fait), vs va proposer les controles de ce type posé sur la fenetre (et enregistrer juste le pointeur vers l'instance)
ca permet de faire par exemple un bouton qui est lié à un combobox (facile à sélectionner en mode design) et que sur le clic du bouton on aille rafraichir le combobox (on a l'instance dans une propriété)
donc si on a en plein ca permet de dire qui est lié

tout ce passe quasiment dans initializecomponent, c'est pour ca que visual studio oblige à avoir cette ligne de code en premier dans le constructeur
ce code est modifiable, mais ce n'est pas recommandable, dès qu'on modifie quelque chose, vs regénère tout le code du fichier .designer.vb et donc on perd son code ajouté
par contre l'inverse est vrai aussi, si on ne touche à rien en mode design et qu'on modifie une ligne de code dans le .designer (puis sauvegarde), au rechargement de la page les modifications sont prises en compte (ca peut etre pratique si la modification graphique est complexe mais que par code ca se fait bien)
tout le code qu'on trouve là peut par contre aider à comprendre comment coder la création de controles à la volée (ou par exemple ajouter des colonnes à tablelayoutpanel et gérer leurs tailles, on voit le code généré en en posant un)

après quand on va dans le custom control ou le usercontrol on peut aussi étendre pas mal le comportement du mode design
en effet le code qui affiche le designer est dans le framework et en .net
il y a l'attribut editor qui permet de définir le type de modification d'une propriété dans le propertygrid (fonctionne aussi à l'exécution vu que ce controle existe)
par exemple la propriété anchor affiche un usercontrol (codé en .net) donc on peut faire ce qu'on veut pour l'édition (liste de choix, usercontrol, fenetre perso)
il y a aussi un attribut pour gérer tout le fonctionnement du controle en mode design, comme rajouter un menu sur la petite flèche en haut à droite (qu'on trouve sur certains controles mais avec peu d'options)
on peut alors créer un usercontrol qui fait container (alors qu'un usercontrol normal, une fois qu'on en pose un on ne peut rien rajouter dessus comme ca le ferait sur un panel)

avec ceci on comprend vite que les controles (et de ceux qu'on créé) sont "vivants" en mode design
donc si tu fais un bouton hérité qui dans son constructeur va lire dans une base de données, quand tu poseras un de ces boutons en mode design, ca tentera de se connecter à la base
c'est souvent ce qui amène à dire à ceux qui font des usercontrol que visual studio est buggé, si on a bug dans son controle (et pas de try catch) vs plante

un dernier petit truc sur l'affichage du designer :
à l'ouverture d'un form en mode design, vs cherche la classe parente du form (bien souvent c'est system.windows.forms.form, mais on peut hériter d'un form qu'on a, permettant d'avoir du code commun sur toutes ces fenetres), il l'instancie, puis exécute le code d'initializecomponent
c'est pour ca que ca plante sur une form qui hérite d'une form qu'on marque mustinherit, vs ne pas appeler le sub new sur la classe de base ...

je n'ai pas parlé des components, ca peut aussi être utile
rappel, form hérite de control, mais control hérite de component (disposable aussi)
component c'est un "control" non graphique, comme le timer, on peut le poser mais il est sur une barre en bas
on peut donc se faire des components
par exemple un component requete, et un controle custom héritant de datagrid qui a une propriété as componentrequete, vs propose alors ceux qu'on a posé et ca simplifie le code d'avoir les 2 liés

etc...

et bien entendu, tout ceci ne concerne en rien WPF qui lui passe pas un traducteur rendu interface / code xaml

(me suis pas vraiment relu, et ca n'est pas complet, mais c'est déjà une bonne base pour qui veut se créer une toolbox améliorée)

MERCI !

Bin là...

Si t'étais dans mon coin, j'te paierais une bière...

Ca fait beaucoup d'info et j'ai l'impression que ça part un peu dans tous les sens donc ça va prendre un peu de temps à bien assimiler mais c'est en tout cas très intéressant.

Merci !

ordonner tout ca aurait pris un peu plus de temps ^^
en testant 2 ou 3 points dans vs on comprend mieux je pense
après si tu as des questions précises n'hésite pas

Pas vraiment de questions précises non. Juste un besoin de compréhension général pour éviter de me retrouver avec des erreurs dont j'ignore tout des causes probables.