Discussion :

[ClaudeBg]

Bonjour,

Je sais utiliser les UITypeEditor, les TypeConverter et les ShouldSerializeProperty, mais je ne trouve pas où je peux accéder à la méthode qui permet au designer d'initialiser les propriétés dans le .design.cs de ma form.

Pour donner un exemple inutile mais simple, si j'ai un contrôle qui dispose d'une propriété qui est un tableau d'entiers. Cette propriété est sérialisée comme suit dans la classe partielle:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
            this.bgTrackBar1.Tick1RelativePositions = new int[] {
        10,
        20,
        30,
        40,
        50,
        60,
        70,
        80,
        90,
        100};

Comment faire pour que le designer écrive le tout en une ligne, comme ceci:

Code :

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

            this.bgTrackBar1.Tick1RelativePositions = new int[] {10,20,30,40,50,60,70,80,90,100};

Je l'ai dit, ça ne sert à rien dans cet exemple, c'est pour rester simple, je cherche juste où et comment intervenir pour les cas où au contraire ça m'est utile (remplacer l'initialisation par un appel à une méthode, à un constructeur avec paramètres etc)

Merci d'avance,
Claude

[thebop]

Bonjour à toi Claude.

A vrai dire j'avais déjà du mal à comprendre la question... Mais alors avec l'exemple c'est encore pire, je n'arrive pas à comprendre ce que tu veux et où tu veux en venir.

[ClaudeBg]

Je vais tenter d'expliquer autrement.

Quand tu places un contrôle dans une form (mettons "MaForm") et que tu modifies les propriétés par défaut de ce contrôle, pour chaque propriété modifiée, le designer ajoute les initialisations correspondantes dans le fichier "maForm.designer.cs".

Par exemple, si tu places un textbox dans une form, tu obtiens ceci dans le fichier designer.cs:

Code :

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

1
2
3
4
5
6
7
            // 
            // textBox1
            // 
            this.textBox1.Location = new System.Drawing.Point(234, 243);
            this.textBox1.Name = "textBox1";
            this.textBox1.Size = new System.Drawing.Size(100, 20);
            this.textBox1.TabIndex = 1;

Tu vois qu'à chaque propriété "non par défaut", tu as une ligne.
Par exemple, le fait de modifier la position du textBox produit la ligne :

Code :

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

            this.textBox1.Location = new System.Drawing.Point(234, 243);

Donc, "quelque part" il y a une méthode qui précise que pour une propriété de type "Point", le designer doit créer une ligne telle que celle-ci.

Ce que je voudrais, c'est qu'avec certaines propriétés de mes contrôles, je puisse décider de la ligne qui va être ajoutée au lieu d'obtenir une ligne prévue "par défaut" pour ce type de propriété.

Pour garder l'exemple du point, je voudrais par exemple que plutôt que d'obtenir

Code :

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

            this.textBox1.Location = new System.Drawing.Point(234, 243);

Le code généré automatiquement soit par exemple

Code :

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

this.textBox1.ChangeLocation(234,243);

Or, je sais tester des valeurs par défaut complexes avec ShouldSerialize, je sais faire un convertisseur de type pour saisir en string dans la grille de propriété, je sais faire un éditeur de type, MAIS je ne trouve pas où et quoi surcharger pour que, par exemple, la propriété "Location" de mon contrôle ne produise plus la ligne par défaut dans .designer.cs, mais au contraire la ligne de mon choix.

J'espère qu'expliqué comme ça, c'est plus clair

Claude

[thebop]

Très clair oui. Mais si je ne m'abuse tout ça est simplement automatisé par VS et n'a rien à voir avec le framework même des winforms.

Donc bien que je comprenne ton problème je ne saisis pas trop pourquoi tu parles de méthodes ou de surcharges.
Je suppose pour ma part que ce sont des options à paramétrer dans VS... Quant à savoir si c'est possible et où elles sont alors là je sèche complétement donc je ne peux pas t'aider.

[Guulh]

Autant que je sache, le contenu de la méthode InitializeComponents n'est constitué que d'affectation de valeurs à des propriétés, et marginalement d'appels de méthodes (notamment pour spécifier la liste des contrôles d'un contrôle).
Le designer doit juste savoir comment initialiser une instance de chaque type, pour l'affecter à la propriété, d'où le this.Location = new Point(bidule) que tu cites.

Et je vois pas trop à quoi te servirait ce que tu cherches à faire ; la tendance dans la déclaration d'interfaces graphiques est d'oublier que c'est du code, et de ne caractériser les widgets que par l'ensemble de leurs propriétés. Comme HTML ou XAML, ou les bon vieux fichiers res de Win32, par exemple.

[ClaudeBg]

Mais si je ne m'abuse tout ça est simplement automatisé par VS et n'a rien à voir avec le framework même des winforms.

Le reste aussi est "automatisé".
Tout ce que j'ai vu de VS jusqu'à présent, c'est qu'il repose aussi sur le framework et que l'esprit est plutôt de rendre tout accessible. Tout le designer, c'est du framework, je n'ai rien vu de spécifique à VS jusqu'à présent à ce niveau. Pour ce qui est de winform, j'ai posté ici parce que le code est créé dans la classe de la form.

Je comprendrais mal qu'on puisse décider quand VS sérialise, qu'on puisse agir au niveau des grilles de propriétés, de l'éditeur lui-même, de tout ce qui concerne le designer, de l'intellisense, etc, mais que par contre on ne puisse pas "bêtement" modifier les lignes de codes générées automatiquement.

Tu as peut-être raison, mais alors c'est dommage.

Donc bien que je comprenne ton problème je ne saisis pas trop pourquoi tu parles de méthodes ou de surcharges.

Parce que tout ce qu'il est possible de modifier dans le comportement du designer se fait de cette façon, et qu'on est en environnement objet.

Je suppose pour ma part que ce sont des options à paramétrer dans VS

Possible (si je ne sais pas comment on fait je ne peux pas prétendre savoir comment on ne fait pas) mais je vois mal une "option" consistant à lister l'intégralité des lignes de codes générées par VS. Et si c'était une option à paramétrer, ça voudrait dire que le code ne serait pas portable, puisque la moindre modif dans le designer par celui qui récupère les sources induirait de remettre les lignes générées automatiquement à leur aspect par défaut.

Quant à savoir si c'est possible et où elles sont alors là je sèche complétement donc je ne peux pas t'aider.

Tant pis, merci d'avoir essayé.

Claude

[ClaudeBg]

Je n'avais pas vu la seconde réponse.

Le designer doit juste savoir comment initialiser une instance de chaque type, pour l'affecter à la propriété, d'où le this.Location = new Point(bidule) que tu cites.

Oui, je comprends ça pour les types primitifs, comme "int". Ca, ça pourrait être figé. Idem pour "class" (déjà ça devient plus dur).

Mais justement, "Point", c'est une classe du framework,et le framework évolue. Je vois mal prévoir dans VS l'intégralité de toutes les classes existantes et leur initialisation, ce serait du reste contraire à l'esprit objet (ça devrait être indiqué dans la classe Point ou dans la propriété Location, et pas dans VS, tout comme ToString() est définit dans Point et pas dans une classe générique reprenant tous les Tostring possibles en fonction du type). Donc, VS devait générer une ligne identique pour toutes les propriétés de type "class".

Or, Point dispose de 4 constructeurs et VS en choisis explicitement un avec deux paramètres. Où celà est-il précisé et comment reproduire ce comportement?

Si je crée une classe publique similaire à Point avec 2 propriétés, i et j, et avec deux constructeurs, un sans paramètre et un avec deux paramètres, et que j'utilise cette classe comme type pour une propriété d'une autre classe, le designer ne me crée jamais la ligne

Code :

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

this.mapropriete = new maclasse(0,1);

mais il me crée une ligne du genre :

Code :

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

this.bgTrackBar1.myproperty = ((BgControls.maclass)(resources.GetObject("bgTrackBar1.myproperty")));

Par contre, si je définis une propriété de type "Point", alors le designer est "correct". Moralité, j'en conclus que dans la classe "Point" il y a quelque chose qui indique au designer comment générer la ligne, ce dont ne dispose pas ma classe "comparable".

Et je vois pas trop à quoi te servirait ce que tu cherches à faire ; la tendance dans la déclaration d'interfaces graphiques est d'oublier que c'est du code, et de ne caractériser les widgets que par l'ensemble de leurs propriétés. Comme HTML ou XAML, ou les bon vieux fichiers res de Win32, par exemple.

Ce que je cherche à faire, c'est à ce que pour mes propres propriétés particulières d'un type non basique le designer me produise des lignes "plus propres" que ce qu'il ne fait par défaut, de pouvoir forcer l'appel d'un constructeur avec paramètres, et autres choses intéressantes.

Se le designer utilise le constructeur Point avec 2 paramètres pour la propriété "Location" et qu'il ne le fait pas avec ma propriété basée sur une classe perso contenant aussi un constructeur avec 2 paramètres, j'ai pensé que ça voulait dire que "Point" précisait quelque part au designer comment générer les lignes d'initialisation.

C'est ça que je cherche à faire également. Si MS a jugé utile de ne pas utiliser les générations automatiques par défaut pour ses propres classes, ça doit également être utile pour les autres, non?

Du reste, puisqu'on parle de Point, j'ai un peu de mal avec ça : Le msdn indique que c'est une classe mais pointe sur les explications d'une structure. Reflector indique que c'est une structure, mais elle possède un constructeur sans paramètre et le msdn indique qu'une structure ne peut pas contenir de destructeur ni de constructeur sans paramètre. J'avoue m'y perdre un peu.

Merci,
Claude