Discussion :

[ClaudeBg]

Bonjour,

Je me retrouve confronté à plusieurs questions consécutives :

J'ai une série de contrôles dérivés soit de Control, soit d'autres controles "officiels". Pour ces contrôles, j'utilise un designer pour ajouter des fonctionnalités (snaplines, verbs, selectionrules,actionlists) et à partir de ces designers j'utilise des classes DesignerActionList pour créer des smartags.

Jusqu'ici, aucun problème, ça fonctionne avec tous mes contrôles.
Mais voici que je dérive un "bête" contrôle de RichTextBox, et me voici droit dans une série d'interrogations que je n'avais pas encore rencontrées.

1) J'essaye de reproduire le fonctionnement du smartTag d'un richTextBox "Modifier les lignes de texte". J'arrive bien à placer ma propriété "Lines", mais évidemment j'obtiens la même chose que dans la propertyGrid : une zone texte suivie d'un bouton <...> et non un lien ouvrant l'éditeur de tableaux string directement. Ceci est donc ma première question, mais je pensais trouver aisément la solution. Je sais que je dois passer par une méthode, mais j'ignore en fait comment afficher l'éditeur de collection.

2) Pour tenter de voir comment on a procédé dans le contrôle original, je lance donc reflector. J'arrive dans ma classe "RichTextBox", qui, comme je m'y attendais, est flanquée de l'attribut :
[Designer("System.Windows.Forms.Design.RichTextBoxDesigner,....

Donc, je me dis en bonne logique : regardons dans System.Windows.Forms.Design après la classe RichTextBoxDesigner, qui me mènera aux smartTags.

Et là, surprise, je ne trouve rien du tout ?? Est-ce que je fais une erreur de raisonnement, ou est-ce que ce designer est invisible (?) ou ne fait pas partie du framework, ou autre chose? C'est ma seconde question, découlant de la première, et qui m'interpelle d'avantage.

Enfin, après avoir fait l'impasse provisoire sur ce smartTag, je poursuis l'écriture des autres, et là, nouvelle surprise : j'obtiens bien tous mes smarttags correctement placés et décrits, MAIS il m'en reste un du RichTextBox original, le smarttag "Ancrer dans le container parent" qui reste présent. D'où vient-il et comment m'en défaire? Jusqu'ici, en surchargeant la méthode GetSortedActionItems() je renvoyais mes nouveaux items (new DesignerActionItemCollection()), mais en fait c'est vrai SAUF pour celui-là. Une explication? J'ai regardé s'il n'y avait pas un attribut spécifique sur la propriété Dock du RichTextBox, mais elle n'est même pas surchargée.

Merci d'avance,
Claude

[Pol63]

reflector ne charge pas tous les assemblies par défaut
le designer du richtextbox doit etre trouvable, surement dans system.design

pour le propertygrid, regarder la classe UITypeEditor, on peut la dériver et ensuite la mettre en attribut soit sur une classe (pour agir sur toutes les propriétés de ce type) soit sur une propriété

[ClaudeBg]

Merci pour les réponses.
Je précise :

En ce qui concerne reflector, ce que je veux dire c'est que l'attribut précise bien :
[Designer("System.Windows.Forms.Design.RichTextBoxDesigner

Je suis donc sensé trouver RichTexBoxDesigner dans System.Windows.Forms.Design. Or, j'ai cet assembly visible dans reflector mais il ne contient pas RichTextBoxDesigner. Ou est-ce que je me trompe?

Pour le propertyGrid, ce que je veux dire c'est que si je crée un smarTag, j'obtiens ceci :



Je dois cliquer sur le bouton <...> pour lancer automatiquement l'éditeur de collections string.

Alors que moi je veux une méthode (ça je sais faire) qui ouvre directement l'éditeur de collections string (ça je ne sais pas faire), comme ceci :



Et en ce qui concerne le smartTag que je veux supprimer, c'est le dernier de la première image (ancrer dans le container parent), ce n'est pas moi qui l'ai placé il s'y trouve d'office et j'ignore par quel méthode il arrive là.

Merci

[Pol63]

alors

un namespace n'a rien à voir avec un assembly
et en francais, le nom de domaine ("préfixe" de la classe) n'est pas forcément lié à la dll dans laquelle il est présent


pour transformer ta propriété de smarttag "lignes de texte" en lien qui ouvre une fenetre, il suffit de faire un lien
"visitez le site de bigonoff" ca doit etre toi qui l'a mit donc tu dois savoir comment on fait, ca appelle une sub
et dans cette sub, vu que tu peux taper du code .net tu peux ouvrir une fenêtre en lui passant l'instance de richtextbox et qui à la fermeture va modifier la propriété


et enfin pour le "ancrer dans le conteneur parent" qui apparait, à priori ca doit venir de la classe que dérive
si tu pars de controldesigner tu ne devrais pas l'avoir (d'ailleurs confirmation du premier point, reflector me dit que System.Windows.Forms.Design.ControlDesigner n'est pas dans system.windows.forms.dll mais bien dans system.design.dll)

[un doute s'installe, jetage d'oeil dans du code]

en fait moi c'est la propriété ActionLists que j'override sur le designer pour appeler créer une instance de ma dérivation de DesignerActionList en overridant GetSortedActionItems
ce qui semble correspondre à ce que tu fais
tu ne "concatènes" pas ta liste avec la liste de base.GetSortedActionItems ?

enfin bref, là je vois pas trop, en général j'hérite de controldesigner ou parentcontroldesigner, rarement de choses de plus haut niveau ...

[ClaudeBg]

un namespace n'a rien à voir avec un assembly
et en francais, le nom de domaine ("préfixe" de la classe) n'est pas forcément lié à la dll dans laquelle il est présent

Ok, je pensais que c'était lié par convention, j'ai effectivement confondu les deux, merci.

Du coup, le designer se trouvait bien dans System.Design.dll, et effectivement cette dll n'était pas chargée automatiquement par Relector.
Après chargement explicite, j'ai pu poursuivre mes investigations (j'y reviens).

pour transformer ta propriété de smarttag "lignes de texte" en lien qui ouvre une fenetre, il suffit de faire un lien
"visitez le site de bigonoff" ca doit etre toi qui l'a mit donc tu dois savoir comment on fait, ca appelle une sub
et dans cette sub, vu que tu peux taper du code .net tu peux ouvrir une fenêtre en lui passant l'instance de richtextbox et qui à la fermeture va modifier la propriété

Oui, mais ça je sais le faire, c'est pour ça que j'ai précisé "ça je sais faire", il suffit d'utiliser un DesignerActionMethodItem. Je sais faire par exemple un lien qui dit "passer en mode vertical" et avec le texte qui change à chaque action en rafraichissant le smartTag etc.
Ce que je ne sais pas, c'est "simplement" que mettre dans le code en question pour ouvrir l'éditeur de collections string qui apparaît lorsque je clique sur le bouton <....>.

Bon, vu ta précédente réponse, j'ai pu examiner comment RichtTextBoxDesignerActionList procède : il appelle simplement :

Code :

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

EditorServiceContext.EditValue(this.designer, base.Component, "Lines");

Mais Microsoft a eu la délicate attention de déclarer EditorServiceContext "Internal"
Donc, j'ai du pister tout le mécanisme (la programmation objet peut se révéler un plaisir à pister ). J'ai abouti finalement, après bien des méandres à la classe public CollectionEditor , qui est une classe "générique".

De là, j'ai abouti à ce que je cherchais, la classe StringCollectionEditor.
Mais, de nouveau, agréable suprise, , la classe était déclarée "internal".

J'avais déjà eu le même soucis en voulant utiliser TextBoxBase, ce qui m'avait contraint à dériver de TextBox puis à masquer tout ce qui ne m'intéressait pas (comportement pas très logique dans la philosophie objet que nous impose la "protected mania" Microsoft).

N'aiment pas trop qu'on profite trop de leur travail, chez Microsoft, apparemment

Donc, pour résoudre mon problème, je dois m'amuser à redériver de CollectionEditor, et, franchement, juste pour une question de look, ça n'en vaut pas la chandelle, c'est encore plus simple d'ouvrir une simple petite fenêtre de saisie de texte.

si tu pars de controldesigner tu ne devrais pas l'avoir

Ben justement, c'est le but de ma question. Je pars de ControlDesigner et pourtant les autres smarTags ont disparus (logique puisqu'ils n'existent pas dans ControlDesigner) pour tous mes contrôles, SAUF "ancrer..." pour le contrôle dérivé de RichTextBox. Celui-là, il reste.

en fait moi c'est la propriété ActionLists que j'override sur le designer pour appeler créer une instance de ma dérivation de DesignerActionList en overridant GetSortedActionItems
ce qui semble correspondre à ce que tu fais

C'est ce que je fais aussi.
Dans le Designer je fais référence à ma propre classe ActionLists en surchargeant ActionLists :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public override DesignerActionListCollection ActionLists
{
    get
    {
        var actions = new DesignerActionListCollection();
        var designerActionList = new BgRichTextBoxActionList(this.Control);
        actions.Add(designerActionList);
        return actions;
    }
}

puis dans ma classe BgRichTextBoxActionList, dérivée de DesignerActionList je surcharge la méthode GetSortedActionItems :

Code :

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

1
2
3
4
5
6
7
8
 
public override DesignerActionItemCollection GetSortedActionItems()
{
    var items = new DesignerActionItemCollection();
     // Placer les titres
    items.Add(new DesignerActionHeaderItem("Paramètres généraux", "Parametres"));
    ........
    return items;

Je n'ai aucun soucis pour aucun contrôle, sauf le "ancrer" du RichTextBox.

tu ne "concatènes" pas ta liste avec la liste de base.GetSortedActionItems ?

Non, comme tu constates je crées un "new", et de plus les autres smartTags ont bien disparus, ne reste que celui-là.

enfin bref, là je vois pas trop, en général j'hérite de controldesigner ou parentcontroldesigner, rarement de choses de plus haut niveau ...

C'est mon cas également

Claude

[Pol63]

il est possible d'appeler des choses privées ou internal par reflection donc tu doit pouvoir appeler EditorServiceContext.EditValue en 3 ou 4 lignes de code

pour le "ancrer ..." je n'ai donc pas de solutions ... m'enfin c'est pas super grave non plus qu'il reste je pense ...

[ClaudeBg]

il est possible d'appeler des choses privées ou internal par reflection donc tu doit pouvoir appeler EditorServiceContext.EditValue en 3 ou 4 lignes de code

Ah, ok, j'ignorais ça, merci beaucoup.
Me reste à faire des recherches pour savoir comment on procède.

pour le "ancrer ..." je n'ai donc pas de solutions ... m'enfin c'est pas super grave non plus qu'il reste je pense ...

C'est surtout qu'il n'était pas au bon endroit (catégorie) et donc pas très esthétique.
Mais en fait je viens juste de trouver : C'est à cause de l'attribut qui est placé sur la classe du contrôle RichTextBox dont je dérive :

Code :

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

[Docking(DockingBehavior.Ask)]

Lorsque cet attribut est sur "Ask", la requête "ancrer dans le container parent" est d'office présente dans le smartTag même si on renvoie "null" comme ActionList.

J'ai donc finalement ajouté simplement ceci sur la classe de mon contrôle :

Code :

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

[Docking(DockingBehavior.Never)]

et la ligne en question a disparu.

Encore merci,
Claude

[ClaudeBg]

Bon, pour l'éditeur de stringCollection, j'y suis arrivé également (grâce à la piste fournie par Pol63 ), je poste pour celui que ça intéresse :

Voici ma méthode d'appel :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public void EditLines()
{
    // Obtenir le type de la classe EditorServiceContext présente dans System.Windows.Forms.Design (de System.Design.dll)
    var type = Type.GetType("System.Windows.Forms.Design.EditorServiceContext");
    // Obtenir la méthode EditValue (statique) du type EditorServiceContext (il n'y en a qu'une, inutile de filtrer,
    //   mais je filtre quand même au cas d'une évolution future possible du framework ajoutant des méthodes)
    var methode = type.GetMethod("EditValue",new Type[]{designer.GetType(),Component.GetType(),typeof(string)});
    // Exécuter la méthode récupérée en passant les arguments utiles en paramètres.
    methode.Invoke(null, new object[] { designer, Component, "Lines" });
}

J'ignore si j'ai procédé de façon "habituelle", mais apparemment ça fonctionne.

Simplement, je comprends assez mal le concept visant à définir explicitement une classe comme "internal" tout en fournissant des outils permettant de l'utiliser quand même en "external".

J'ai un peu l'impression qu'on passe son temps à mettre un cadenas sur une zone réservée tout en fournissant la clé à tout qui la demande.
Quelque chose doit m'échapper, LOL

En tout cas, merci du coup de main,
Claude

[Pol63]

pour la reflection c'est bien comme ca qu'il faut procéder oui

en fait rien n'est inaccessible en .net, la reflection peut quasiment tout déverrouiller
de plus via reflector le code source de n'importe quel assembly .net est décompilable

mettre des choses privées, internal ou autre sert à rendre accessible certaines choses où non
si tu développes une classe pour une boite à outils pour qu'un autre développeur l'utilise après, y a certaines choses que tu va rendre non accessible pour qu'il n'ait que les membres utiles de visibles et en plus que les membres "dangeureux" soient inaccessibles
mais il pourra quand meme les attendre par reflection (pas donné à tout le monde de comprendre/mettre en place aussi vite que toi)
après le pourquoi du comment, il faudrait demander à microsoft ...

à noter quand même, quand on utilise de la reflection sur autre chose qu'une dll du framework on met soit des try catch, soit des tests pour vérifier que les variables type et méthodes ne sont pas nulles, car autant que le framework ne bouge pas dans le temps, des dll tierses peuvent tout à fait être modifiées, et si le nom d'une méthode change ca plantera ...

[ClaudeBg]

Merci, j'ai bien pris acte de tes explications et de ta remarque.

Je te remercie encore, surtout que ces temps-ci je pose beaucoup de questions, LOL



Claude

[Pol63]

ca fait plaisir de répondre à autre chose que "comment on utilise une variable d'un form sur un autre"