Discussion :

[gaetan13]

Bonjour,
J'ai une petite question théorique.
Je me trouve actuellement dans une classe héritant de DesignerActionList (System.ComponentModel.Design).

Quand je modifiais les propriétés de mon contrôles par le biais de mon ActionList je me suis rendu compte que le designer n'écrivait pas le code correspondant à mes modifications ce qui avait pour conséquence que lorsque je lançais le debug aucune modification sur les propriétés du contrôle n’était exécutée.

J'utilisais parent.control.exemplePropiete pour modifier les propriétés de mon contrôle depuis l'ActionList.

Remarquant que pour n'importe quel contrôle natif du framework tout fonctionnait très bien, j'ai lu le code source et je me suis rendu compte qu'ils modifiaient les propriétés depuis les ActionList comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
TypeDescriptor.GetProperties(base.Component)["SizeMode"].SetValue(base.Component, value);

Ma question est la suivante :

Pourquoi passer par un component qui est une interface pour éditer les propriétés du contrôle, et pourquoi ça fonctionne contrairement à ce que j'avais utilisé au début.

Merci d'avance.

[DotNetMatt]

Une simple recherche sur Google t'aurais donné la réponse

La principale différence entre un User Control, un Custom Control et un Compoent, c'est la façon dont ils héritent dans l'arbre d'héritage :

MyComponent
|-> Component

MyCustomControl
|-> Control
|---> Component

MyUserControl
|-> ContainerControl
|---> ScrollableControl
|-----> Control
|-------> Component

Quand est-ce qu'il faut utiliser quoi ? (ce n'est qu'un avis...)

• Crée un component si tu veux fournir des fonctionnaltiés sans interface (par exemple un Timer, une source de données...).
• Crée un custom control si tu veux avoir un contrôle total sur le rendu visuel du control et que tu n'as pas besoin d'avoir toute une floppée de fonctionnalités inutiles. Comme exemple typique on peut donner les controls avec des fonctionnalités limitées (comme un bouton par exemple).
• Crée un user control si tu dois combiner des controls existants pour pouvoir les réutiliser plus facilement (comme par exemple deux listes avec des boutons qui permettent de déplacer les données de l'une vers l'autre).

[gaetan13]

Merci pour votre réponse très complète. J'ai effectivement trouve des réponses sur la différence entre les deux sur internet... Mais ma question est : pourquoi le désigner ne réécrit pas les propriétés quand on passe par le contrôle et non l'interface IComponent.

[Pol63]

le designer de vs utilise du code .net

quand on modifie une propriété normalement dans le designer, on voit une petite étoile apparaitre sur l'onglet, en faisant sauvegarder on voit bien qu'il enregistre ce qu'on a modifié
l'étoile montre bien que vs est averti qu'il y a une modif et qu'il faut demander à réenregistrer, et donc à passer par la sérialisation du designer

ce code doit donc servir à modifier la propriété en avertissant du changement
en tout cas j'apprends que base.component permet de retrouver le controle lié, moi à l'époque j'avais fait transiter une variable entre les classes ^^

[gaetan13]

Oui, je trouve cela étonnant que le désigner ne soit pas avertit de la modification...
J'ai essayé de trouver dans la source du fw (3.5) du TypeDescriptor où pourrait se trouver un éventuel code appelant la reserialisation par le designer lors du changement de propriété... Mais ça devient super compliqué, la classe implémente des tonnes d'interface et tout

Bref ça restera un mystère je crois ^^

Merci quand même à vous

[Pol63]

il n'y a rien d'étonnant que le designer ne soit pas averti
c'est beaucoup plus connu depuis l'arrivée de wpf, mais pour qu'une propriété puisse avertir quelqu'un de son changement il faut du code (via dependencyobject ou inotifypropertychanged)

donc me parait logique pour ce qui est du designer on doive passer par un classe qui sert à ca