Discussion :

[Kropernic]

Hello,

J'ai créé un toolstrip custom qui est "préconfiguré" dans le sens où il possède déjà des boutons par défaut et certaines des ses propriétés sont initialisées pour correspondre à notre "charte graphique".

Les boutons par défaut sont accessibles à l'utilisation de contrôle via des propriétés qui les exposent. Il est donc possible de, par exemple, rendre le bouton "Editer" non visible si on n'en a pas besoin.
Mais si je ferme la fenêtre d'édition du formulaire où ce contrôle custom est utilisé (je parle donc du mode design dans VS), quand je l'ouvre à nouveau, le bouton "Editer" est de nouveau visible (sa propriété est repassé à True).

Du peu que je connais du fonctionnement du designer de VS, je pense comprendre que c'est car mon contrôle est chaque fois recréer avec un New. Et vu que les boutons par défaut sont ajouter dans le constructeur de mon custom ToolStrip, les modifications sont automatiquement perdues.

Du coup, je cherche à savoir comment vous feriez ce genre de chose.

Si je ne suis pas clair, n'hésitez pas à poser des questions.

Merci d'avance.

Edit : Je me doute bien que je peux initialiser les propriétés Visibles des boutons que je ne veux pas voir dans le constructeur du formulaire qui utilise ce toolstrip custom mais bon, si ça peut garder ses propres paramètres en mémoire... Des settings au sein du projet du usercontrol ?

Edit 2 : Je viens de tester avec des settings au sein du usercontrol et cela ne va pas du tout dans le sens où s'il y a plusieurs exemplaires de ce usercontrol sur le formulaire, tous sont affectés XD. J'aurais cru que cela se cantonnerait pourtant à l'instance mais ce n'est apparemment pas le cas...

[Sankasssss]

Hello Kropernic,

Edit : Je me doute bien que je peux initialiser les propriétés Visibles des boutons que je ne veux pas voir dans le constructeur du formulaire qui utilise ce toolstrip custom mais bon, si ça peut garder ses propres paramètres en mémoire...

Pourquoi vouloir garder les propriétés en mémoire? Le comportement risque-t-il de changer? Mettras-tu un jour cet item visible? Moi perso je l'initialiserais directement par code. j'utilise de moins en moins le designer.

Edit 2 : Je viens de tester avec des settings au sein du usercontrol et cela ne va pas du tout dans le sens où s'il y a plusieurs exemplaires de ce usercontrol sur le formulaire, tous sont affectés XD. J'aurais cru que cela se cantonnerait pourtant à l'instance mais ce n'est apparemment pas le cas...

Les settings ont effectivement une portée globale. Ils ne conviennent donc pas dans ton cas.

Tu pourrais imaginer que ton UserControl expose des propriétés du genre EditIsVisible qui agiraient directement sur leurs composants respectifs, de cette manière tu y aurais accès en mode design et je pense qu'elles resteraient, à tester...

Tu aurais pas un bout de code à passer pour mieux voir et tester (si tu peux...)

[Kropernic]

Hello Kropernic,

Pourquoi vouloir garder les propriétés en mémoire? Le comportement risque-t-il de changer? Mettras-tu un jour cet item visible? Moi perso je l'initialiserais directement par code. j'utilise de moins en moins le designer.

Bin pour le moment (mais ce n'est p-e pas la bonne manière de faire), j'ai donc une classe qui hérite de ToolStrip et dans laquelle il y a 5 propriétés de type ToolStripButton qui correspondent aux 5 boutons par défaut. J'ai choisi d'exposer ces boutons via des propriétés un peu par défaut d'une meilleure solution car je ne savais pas trop comment faire et que je me suis dit que cela laissera la possibilité de modifier l'apparence (ou autre) des boutons si nécessaire.
Mais vu que, en l'état, ça donne juste un bouton sans image et sans texte (sans rien en fait), j'ai mis du code dans le constructeur pour initialiser ses 5 propriétés avec chacune leur bouton respectif bien configuré (une jolie image, un nom adéquat, un texte par défaut, etc.).

Donc quand j'ajoute mon usercontrol dans un nouveau projet, j'ai bien une toolstrip avec 5 jolis boutons qui s'affiche. Et, via les propriétés de ce contrôle, je peux aller modifier les propriétés de ces 5 boutons.

Les settings ont effectivement une portée globale. Ils ne conviennent donc pas dans ton cas.

C'est ce que je viens de constater oui ^^

Tu pourrais imaginer que ton UserControl expose des propriétés du genre EditIsVisible qui agiraient directement sur leurs composants respectifs, de cette manière tu y aurais accès en mode design et je pense qu'elles resteraient, à tester...

Je vais tester cette solution pour voir. Ca rendra le contrôle moins flexible dans le sens où, si pour une raison quelconque, pour l'un deux je veux mettre une autre image, je ne pourrai plus autrement que par code (je crois)

Tu aurais pas un bout de code à passer pour mieux voir et tester (si tu peux...)

C'est un peu délicat vu que c'est du code fait pour le boulot, c'est la société qui en est propriétaire...

[Kropernic]

Sans surprise, avec les propriétés IsXxxxVisible, ça fonctionne bien.

Mais je pense que ça aurait été sympa de pouvoir accéder au bouton via le designer pour modifier l'une ou l'autre chose (l'image, la police, l'alignement, etc.).

Je n'abandonne donc pas ^^

[Sankasssss]

Je me doutais que tu ne pourrais pas mettre le code, on en avait déjà parlé mais avec les indications que tu as données j'ai pu reproduire ce comportement sans soucis.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Imports System.ComponentModel
 
Public Class MyToolStrip
    Inherits ToolStrip
 
    <Category("Items"), _
    Description("First item test.")> _
    Public Property FirstItem As ToolStripItem
 
    Sub New()
        MyBase.New()
        FirstItem = Me.Items.Add("FirstItem")
 
    End Sub
End Class

Je n'avais jamais essayé d'ajouter un élément à un control que j'étendais. En général ,quand je fais ça, c'est soit pour redéfinir ou ajouter un comportement à une méthode existante, soit pour ajouter de nouvelles méthodes. Mais le sujet est intéressant.
Il doit exister une astuce. J'y regarderai à tête reposée demain car là je fatigue tout doucement...

[p.a.t.c.h]

n'est ce pas un problème de sérialisation ?

Un petit bout de code du usercontrol serait un plus pour pouvoir répondre.

[Sankasssss]

Bonjour p.a.t.c.h, bienvenue sur dvp.com

Tu peux essayer avec le code que j'ai mi ci-dessus qui reproduit ce comportement. Une fois cette class crée, il suffit de régénérer la solution, d'intégrer le composant perso sur une form et d'essayer de modifier FirstItem, par exemple ça propriété Text, par le designer.
A la première recompilation il perd toutes les modifications effectuées sur le designer.

[Kropernic]

Je me doutais que tu ne pourrais pas mettre le code, on en avait déjà parlé mais avec les indications que tu as données j'ai pu reproduire ce comportement sans soucis.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Imports System.ComponentModel
 
Public Class MyToolStrip
    Inherits ToolStrip
 
    <Category("Items"), _
    Description("First item test.")> _
    Public Property FirstItem As ToolStripItem
 
    Sub New()
        MyBase.New()
        FirstItem = Me.Items.Add("FirstItem")
 
    End Sub
End Class

Je n'avais jamais essayé d'ajouter un élément à un control que j'étendais. En général ,quand je fais ça, c'est soit pour redéfinir ou ajouter un comportement à une méthode existante, soit pour ajouter de nouvelles méthodes. Mais le sujet est intéressant.
Il doit exister une astuce. J'y regarderai à tête reposée demain car là je fatigue tout doucement...

Merci pour le bout de code Sankasssss ^^. Vu que j'viens d'avoir une promotion ici (3615 mylife), j'fais gaffe de pas faire de connerie comme poster du code que je ne suis pas sensé poster .

N.B. : Faut dormir la nuit mec

[Sankasssss]

N.B. : Faut dormir la nuit mec

H.S. : J'aimerais bien, d'autant plus qu'avec le service d'été je me lève à 5h20

[p.a.t.c.h]

Ok VU avec le code , il s'agit vraisemblablement d'un problème de sérialisation (enregistrement des propriétés de l'Object) des items de ta collection. (de celle héritée de la classe générique toolstrip).

Tu devrais pouvoir surcharger les propriétés en la déclarant sérialisable et en vérifiant que cette sérialisation soit opérationnelle sur les items (qui sont dans la classe de base en Virtual).

Regarde de ce coté et tiens moi informé si tu as besoin d'aide.

Bonjour p.a.t.c.h, bienvenue sur dvp.com

Tu peux essayer avec le code que j'ai mi ci-dessus qui reproduit ce comportement. Une fois cette class crée, il suffit de régénérer la solution, d'intégrer le composant perso sur une form et d'essayer de modifier FirstItem, par exemple ça propriété Text, par le designer.
A la première recompilation il perd toutes les modifications effectuées sur le designer.

[Kropernic]

Ok VU avec le code , il s'agit vraisemblablement d'un problème de sérialisation (enregistrement des propriétés de l'Object) des items de ta collection. (de celle héritée de la classe générique toolstrip).

Tu devrais pouvoir surcharger les propriétés en la déclarant sérialisable et en vérifiant que cette sérialisation soit opérationnelle sur les items (qui sont dans la classe de base en Virtual).

Regarde de ce coté et tiens moi informé si tu as besoin d'aide.

Hello,

J'ai ajouté l'attribut <DesignerSerializationVisibility(DesignerSerializationVisibility.Content)> et ça a l'air de fonctionner pour le peu que j'ai joué avec pour le moment.

Je n'ai encore jamais vraiment utilisé les attributs. C'est comme cela que tu voyais la chose?

[p.a.t.c.h]

La sérialisation (enregistrement des objets en binaire ou XML) et les attributs (ces espèce de petits signes <...> avant la déclaration en vb net) sont entre autres des fondamentaux des contrôles dans net.
Ce sont eux qui définissent le comportement/visibilité des ces objets, notamment lorsqu'ils n'ont pas encore d'instance (comme dans le designer de VS), net permet d'accéder à ces éléments par les attributs pour modifier le comportement hérité.

Le fait de préciser comment et si sérialiser (sauver pendant le design) une propriété <DesignerSerializationVisibility(DesignerSerializationVisibility.Content)> peut permettre de résoudre, cependant toolstrip étant un container et items ses contenus, il faut que chaque objet (container et inclus) soit sérialisable ('sauvable').

Où dans le code d'exemple a tu introduit l'attribut et quelle surcharge a tu fait ?

Hello,

J'ai ajouté l'attribut <DesignerSerializationVisibility(DesignerSerializationVisibility.Content)> et ça a l'air de fonctionner pour le peu que j'ai joué avec pour le moment.

Je n'ai encore jamais vraiment utilisé les attributs. C'est comme cela que tu voyais la chose?

[Kropernic]

J'ai juste fait ceci :

Code :

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

1
2
<DesignerSerializationVisibility(DesignerSerializationVisibility.Content)>
    Public Property TsbDelete As ToolStripButton

[p.a.t.c.h]

c'est pour ça que je te demandais ton code ,tu l'as mis dans les déclarations des tes objets inclus.

OK c'est bien cela qu'il faut faire (faire de même avec tous les classes/objets/propriétés inclus) si tu veux qu'il garde (sérialise) les valeurs du designer.

NB il faut pour cela que la classe/object/propriété soit sérialisable (là encore il faudra peut être poser un attribut sur l'objet lui-même , si ce n'est déjà pas la cas).

Salutations

J'ai juste fait ceci :

Code :

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

1
2
<DesignerSerializationVisibility(DesignerSerializationVisibility.Content)>
    Public Property TsbDelete As ToolStripButton

[Kropernic]

Si je comprends bien, dès qu'on a une propriété/un objet qui est plus évolué qu'un type de base (integer, string, boolean, etc.), il faut utiliser cet attribut pour que le contenu de cet objet soit sauvegardé.
Autrement, ça recrée un objet neuf avec les paramètres d'usine.

[p.a.t.c.h]

Bonjour,

Non absolument pas :
Quand on créé un objet évolué ou pas les mêmes règles s'appliquent : Héritage, simplement les attributs de sérialisations des objets simples vous conviennent, celle de l'objet évolué non.

Si le concepteur de l'objet a prévu un attribut c'est celui-ci qui s'applique, sinon c'est celui de la classe de base de l'objet en remontant l'héritage.

En l'occurrence les attributs sont héritables au même titre que les propriétés/évènements/méthodes (si le concepteur de l'objet a prévu/autorisé l'héritage comme pour une propriété/méthode/évènement sauf que les mots clés/syntaxe sont différents).

Il y a d'excellents topics sur ce sujet : http://vincentlaine.developpez.com/t...stomattributs/

Les attributs de sérialisation sont des attributs parmi d'autres et répondent au même règles.

En l'occurrence dans votre cas le 'toolstripbutton' n'était pas sérialisable en l'état (pour un problème d'héritage, notamment d'interface, d'attribut, d'implémentation, je n'ai pas cherché) et vous avez du préciser que vous vouliez que les propriétés de l'objet définies lors du design soient sauvées selon son contenu et non selon son héritage (sa visibilité héritée).

NB Lorsque quelqu'un ne veux pas qu'un attribut soit hérité, qu'un objet soit sérialisé, qu'une propriété ai tel ou tel comportement c'est qu'il y a une raison (sauf cas d'oubli ou de limitation technique )
Charge au programmeur à prendre ou non le risque d'y déroger, en l'occurrence je ne vois pas de danger dans votre raisonnement.

Salutations

Si je comprends bien, dès qu'on a une propriété/un objet qui est plus évolué qu'un type de base (integer, string, boolean, etc.), il faut utiliser cet attribut pour que le contenu de cet objet soit sauvegardé.
Autrement, ça recrée un objet neuf avec les paramètres d'usine.