Bonjour,
 
Je souhaite écrire un contrôle utilisateur personnalisé en C#, pour lequel je voudrais définir un champ complexe éditable via la fenêtre de propriétés (dans le même style que le champ Size, qui étant une structure, peut être édité dans le concepteur d'un coup ("240; 200" ) ou par parties si on clique sur le + (Width "240" Height "200" ).
J'ai écrit la classe correspondant à mon champ complexe, j'ai écrit le TypeConverter qui va avec, j’obtiens bien l’effet souhaité dans l’éditeur de propriétés de mon contrôle (je peux éditer le contenu de mon champ complexe en une seule ligne ou par élément).
Cependant, quand je regarde le résultat dans le code généré (dans FormMachin.Designer.cs), je n’obtiens pas du tout la même chose que ce qui est généré pour les types complexes standard.
Pour un champ Size, le concepteur génère le code :

alors que mon champs personnalisé génère le code (en remplissant des merdes dans le fichier .resx) :

Une idée de ce qu’il faut implémenter / spécifier pour que le concepteur me génère le code suivant pour mon champ personnalisé ?

Une inspection des fichiers de définition correspondant au type Size ne m'a pas aidé...
 
 
Merci !

Aidé par Mono, j'ai maté dans le source de SizeConverter et trouvé qu'il fallait implémenter une conversion vers InstanceDescriptor.
 
Sujet résolu

Note supplémentaire pour ceux qui auraient le problème.
 
Quand on implémente un TypeConverter, l'éditeur de propriétés de Visual Studio (2005 et 2008, 2003 non concerné par le problème) pète un cable dès qu'on a compilé son projet une fois. Il n'arrive plus à récupérer les valeurs, pond des erreurs genre "j'ai pas réussi à convertir un ClassTruc en ClassTruc ", et bouzille tous les champs utilisant le dit TypeConverter. Tout se remet en marche (en ayant perdu ses valeurs si on a eu le malheur d'enregistrer) une fois visual redémarré.
 
La solution donnée est de faire changer le numéro de version de l'assembly contenant les controles personnalisés (avec *) :
 
>>>>>>>  
 
The type converters go straight to the CLR's cache of type information and  
do not go through the type resolution service implemented by the project  
systems. This means that the CLR will return the type from the assembly it  
had previously loaded prior to the rebuild - and the conversion will fail  
since the type on the design surface is being loaded from the newly built  
assembly. I verified that you can work around this by ensuring the version  
number of the class library project gets auto-incremented on each build.  
You do this by the following:
1) Bring up properties on the class library project
2) Select the "Application" tab and click the "Assembly Information..."  
button.
3) In version the field set the last entry to a "*" - so it should say: 1 0  
0 *
 
Now whenever the classlibrary is built, the revision number (the last digit  
of the version) will be auto-incremented. This forces the CLR to invalidate  
the entry it has cached and load the new one.
<<<<<<
 
(From http://www.velocityreviews.com/for [...] tudio.html )