Sous-classer un composant (Panel, contrôle) et l'intégrer au designer !

Bonjour,

Je commence souvent mes messages par "Avec Cocoa sous MacOS X on fait comme ça...", mais c'est pour expliquer pourquoi j'ai du mal à retrouver certains concepts avec .NET qui a une approche différente.

Voici :
"Avec Cocoa sous MacOS X", si on crée une sous-classe d'un contrôle (NSView, NSButton, etc...) il est possible de faire lire le fichier .h à InterfaceBuilder (le designer d'interface) pour lui permettre d'intégrer ces nouveaux contrôles. À l'écran, dans le designer, ils ont alors l'aspect de leur superclasse (NSView ou NSButton), mais dans le code, ils sont sous-classés. Il est donc très facile de créer et utiliser de nouveaux contrôles et de redéfinir leur comportement.

J'aimerais faire la même chose en .Net (windows forms) avec Visual Studio 2005.

J'ai essayé la même approche : je crée (à la main) une sous classe de System::Windows::Forms:: Panel, que j'appelle disons MyPanel. Comme je n'ai pas trouvé de moyen d'informer le designer de l'existence de MyPanel.h, je crée un Panel normal dans l'interface, puis, dans le code automatiquement généré, je remplace gcnew System::Windows::Forms:: Panel par gcnew MyPanel; (bien sûr j'ai un #include qui traîne)
Tout marche très bien.
SAUF QUE
Tout marche bien, comme prévu, à l'éxécution. Mais à partir du moment où j'ai modifié le gcnew, le designer n'est plus capable d'afficher la fenêtre contenant le panel. Il me crache des erreurs
"Type MyPanel introuvable, assurez-vous que l'assembly qui contient ce type est référencé. Si ce type est un composant de votre projet de développement, assurez-vous que le projet a été créé comme il se doit"

Alors ma question est : comment faire ?

J'ai lu à droite à gauche que j'aurais tout intérêt à dériver UserControl pour ça (Ajouter > Nouvel élément > Contrôle Utilisateur...) sauf que j'ai le même problème : je n'arrive pas à informer le designer de son existence, et donc je ne sais pas déposer un tel nouveau contrôle dans l'interface sans modifier (et donc invalider) le code sous-jacent.

+
Chacha

Normalement, si tu crées un UserControl, tu peux l'ajouter à la barre d'outil et le glisser déposer sur ta form.
C'est cette action qui te fait une erreur sur le designer ?

Je n'arrive pas à le glisser/déposer !
J'essaye d'attraper le .h, mais il ne se déposer pas dans la boîte à outils. Et je n'arrive rien à "attraper" dans le designer du UserControl...

si tu as créé un userControl, il faut glisser-déposer l'assembly, pas le .h

regarde à partir d'ici dans ce tuto http://nico-pyright.developpez.com/t...ol/#Lattributs

Citation:

---

Envoyé par nico-pyright(c)

regarde à partir d'ici dans ce tuto http://nico-pyright.developpez.com/t...ol/#Lattributs

---

Merci !

En fait, ça ne va pas.
Soit je n'ai pas compris, soit c'est incroyablement peu praticable.
Ce que j'ai trouvé dans le tutorial, c'est qu'un nouveau composant est créé et compilé comme projet autonome. Or, je compte, moi, l'utiliser dans un certain projet, où je veux redéfinir son comportement de telle sorte qu'il utilise certains objets/classes/méthodes de ce même projet...
Comment faire ?

si c'est dans le meme projet, il faut référencer le projet plutot qu'une dll, c'est le meme mécanisme, juste un onglet différent

Toujours pas...
-J'ai bien créé mon PreviewPanelControl (qui dérive de UserControl) comme nouveau projet au sein de ma "solution".
-Je l'ai compilé, et j'ai importé la DLL dans la boîte à outils
-Je peux m'en servir dans le designer du projet initial de ma "solution"
Ça, ça fonctionne

Par contre, j'ai redéfini des méthodes de ce PreviewPanelControl, et je fais appel à du code venant du projet initial de ma "solution". Et forcément, quand il compile, il ne trouve pas tout le code.
Je pourrais donc dupliquer mes fichiers sources pour les compiler dans les deux projets de la solution.

Mais qu'est-ce que c'est lourd !

Non, franchement, sous-classer un élément d'interface utilisateur, en .NET, c'est forcément une galère de ce genre ?

+
Chacha

[edit]
Ah, ben ça n'a pas manqué... vu que le code est compilé dans la dll du PreviewPanelContol et dans l'exe du programme initial, il y a du code dupliqué et ça ne compile pas.

je comprends pas, si tu rajoutes des méthodes dans ton userControl, il faut recompiler pour que ton programme qui référence l'userControl puisse etre au courant des modifications

Ok, j'explique un peu mieux.

J'ai, dans une "solution" S, un projet Toto, qui déclare, implémente, et manipule une classe Titi (Titi.h et Titi.cpp).

Je veux créer une sous-classe "MyControl" de UserControl, qui dans une méthode redéfinie, manipule des objets Titi.

Pour créer cette sous-classe, je suis obligé d'ajouter un projet "MyControl" à ma solution S.
Ensuite,dans MyControl.cpp, pour manipuler les objets de type Titi, je dois include Titi.h. Il me faut donc importer Titi.h et Titi.cpp depuis le projet Toto vers le projet MyControl.
Du coup, le projet MyControl crée bien sa dll, avec le code de Titi.

Du côté du projet Toto, vu qu'il est lié à MyControl.dll, il refuse de recompiler Titi.h et Titi.cpp, sous prétexte que tout est déjà dans MyControl.dll.

Et il y a des erreurs en cascade : à chaque fois que j'ai cru contourner le problème, il y avait d'autres soucis (le designer qui se remet à ne plus marcher, etc...)

Bref : le designer de Visual est vraiment restrictif : tout est sa faute. S'il acceptait que dans son code auto-généré, on remplace les instanciations de classe standard (Panel, Button...) par des sous-classes, alors tout irait bien ! Mais il prétend ne pas connaître les classes (malgré les include et autres) et refuse alors de fonctionner.

+
Chacha

mais tu n'as pas à réinclure toto.h et toto.cpp dans ton projet
si tu références l'assembly, tu l'utilises directement
si tu réinclus le code, ca ne sert à rien de créer la dll

Citation:

---

Envoyé par nico-pyright(c)

mais tu n'as pas à réinclure toto.h et toto.cpp dans ton projet

---

Si mon user control doit manipuler des objets titi, il foit bien include titi.h
Si mon projet toto veut appeler des méthodes du UserControl, il doit bien en importer les headers.

Citation:

---

si tu réinclus le code, ca ne sert à rien de créer la dll

---

J'aurais justement bien aimé me passer d'une DLL pour une bête sous classe de contrôle !

+
Chacha

si tu utilises un UserControl, donc une assembly .Net, tu n'as pas besoin d'inclure le .h
l'assembly est auto-descriptive

Citation:

---

Envoyé par nico-pyright(c)

si tu utilises un UserControl, donc une assembly .Net, tu n'as pas besoin d'inclure le .h
l'assembly est auto-descriptive

---

Oui mais dans mon code à moi, j'ai bien besoin du .h pour valider mes appels de fonction.

Cela dit, après de multiples recherches, j'ai enfin compris le principal problème que j'avais.
En réalité, il est tout à fait possible de créer de nouveaux UserControls compatibles avec le designer sans créer de nouveaux projets et DLLs (et donc sans avoir ces problèmes de .h/pas .h). Si j'ajoute un UserControl à mon projet en cours, je n'ai qu'à inclure l'exe du projet dans la boîte à outils du designer (Choisir les items, etc.) C'est d'ailleurs ce que tu me disais (inclure l'assembly).
Or, c'était la première chose que j'avais essayée avant de poster sur ce forum, et comme ça n'avait pas marché, j'avais cherché d'autres solutions (donc en postant).
Et pourquoi cela n'avait-il pas marché ? J'obtenais une erreur bizarre, de exe invalide, avec plusieurs TLS... (super clair, donc). Je pensais donc simplement avoir mal deviné ce qu'il fallait faire. En réalité, c'est parce que mon code n'est pas compilé en /clr:pure, du fait de mon utilisation intensive de code C/C++ de base et de librairies tierces en C. Et dans ce cas, mon assembly ne peut contenir de UserControls compatibles avec le designer...
Rajoutons à cela un bug apparemment bien connu :
https://connect.microsoft.com/Visual...dbackID=144156

Au final, voici un bel imbroglio dont j'ai eu du mal à me dépêtrer.

Merci en tous cas pour ta ténacité. Et à charge de revanche... (Sans doute pas en .NET, mais en Cocoa, là je maîtrise :-)

+
Chacha