Discussion :

[MoonlightSwamper]

Bonjour

Je m'interroge sur ce qui semble être au premier abord une bizarrerie sans logique du langage. Je prends le cas de trois propriétés :
- Size
- Location
- Linkarea (propriété de la classe Linklabel)

Ces trois propriétés ont en commun d'être de structures, qui plus est de la même forme (à savoir, deux integer). Ce qui explique qu'on peut toutes trois les modifier par la syntaxe : Objet.propriété = New propriété(x, y)

Le hic, c'est lorsqu'on cherche à éviter cette syntaxe en passant par les "sous-propriétés" (je ne connais pas le terme adéquat). Là, tous aux abris, il semble qu'il y ait une solution différente à chaque fois.

1. Pour Size, on peut directement utiliser les sous-propriétés Width et Height, par exemple en écrivant : Button1.Width = 300

2. Pour Location, on peut aussi utiliser les sous-propriétés... à condition d'utiliser d'autres noms que ceux qui sont fournis quand on déploie l'arborescence de la structure dans la fenêtre des propriétés. X et Y sont donc inutilisables, mais on pourra en revanche utiliser Top et Left.

3. Pour Linkarea, on ne peut rien utiliser du tout. Ni Truc.Linkarea.Length ni Truc.Length ne sont acceptés dans une affectation (on reçoit un charmant message "Cette expression est ne valeur et ne peut donc être la cible d'une assignation" - l'aide de MSDN sur ce point semble avoir été écrite en serbo-croate et jamais traduite).

Une âme charitable pourrait-elle m'éclairer ?

[tomlev]

1. Pour Size, on peut directement utiliser les sous-propriétés Width et Height, par exemple en écrivant : Button1.Width = 300

Bah la justement tu ne touches pas aux sous-propriétés... tu accèdes aux propriétés Width et Height du bouton, pas de la Size. En fait la propriété Size sert juste à récupérer ou modifier à la fois la largeur et la hauteur ; dans la classe Control, la largeur et la hauteur sont stockés séparément.

Le fait que les propriétés de Size s'appellent comme celles du contrôle est purement arbitraire, c'est juste que c'était logique. Elles auraient aussi bien pu s'appeler Titi et Toto, mais ça n'aurait pas été très pratique...

2. Pour Location, on peut aussi utiliser les sous-propriétés... à condition d'utiliser d'autres noms que ceux qui sont fournis quand on déploie l'arborescence de la structure dans la fenêtre des propriétés. X et Y sont donc inutilisables, mais on pourra en revanche utiliser Top et Left.

Idem que pour Size, sauf qu'ici ils n'ont pas choisi les mêmes noms.

3. Pour Linkarea, on ne peut rien utiliser du tout. Ni Truc.Linkarea.Length ni Truc.Length ne sont acceptés dans une affectation (on reçoit un charmant message "Cette expression est ne valeur et ne peut donc être la cible d'une assignation" - l'aide de MSDN sur ce point semble avoir été écrite en serbo-croate et jamais traduite).

Je suppose que ce qui te pose problème est que tu ne peux pas faire ça :

Code :

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

1
2
linkLabel1.LinkArea.Start = 0
linkLabel1.LinkArea.Length = 10

C'est lié au fait que LinkArea est une structure, donc un type valeur. La principale caractéristique des types valeurs est qu'ils sont copiés par valeur, et non par référence. Donc quand tu accèdes à linkLabel1.LinkArea, tu récupères une copie du LinkArea du LinkLabel. Donc .Start et .Length accèdent donc en fait aux propriétés d'une copie de l'objet LinkArea, et si tu modifies la copie, ça ne modifie pas l'objet d'origine (celui du LinkLabel). En pratique, ce n'est pratiquement jamais ce que l'on veut faire, et donc le compilateur le détecte et indique une erreur.

A la place, tu peux faire ça :

Code :

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

linkLabel1.LinkArea = New LinkArea(0, 10)

Si tu veux modifier seulement une des propriétés (Start ou Length), tu peux faire comme ça :

Code :

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

1
2
3
4
5
6
' Obtenir une copie de la valeur actuelle
LinkArea area = linkLabel1.LinkArea
' Modifier la copie
area.Length = 12
' Affecter la copie à la propriété
linkLabel1.LinkArea = area

[MoonlightSwamper]

Un grand merci pour cette réponse.
Je reste tout de même fort perplexe devant les motivations qui ont conduit, face au même problème, les concepteurs du langage à adopter trois solutions différentes... qui toutes trois apparaissent néanmoins exactement sous une même forme dans la fenêtre des propriétés.
On aurait voulu ajouter des complications inutiles qu'on ne s'y serait pas mieux pris...

[tomlev]

Un grand merci pour cette réponse.
Je reste tout de même fort perplexe devant les motivations qui ont conduit, face au même problème, les concepteurs du langage à adopter trois solutions différentes...

Mais justement, il n'y a pas 3 solutions différentes... c'est la même situation dans les 3 cas : une propriété qui renvoie un objet de type valeur.

Ce qui change, c'est que certaines classes ont un moyen d'accéder directement aux "sous-propriétés" et d'autres non. Mais ça n'a rien à voir avec le langage proprement dit, c'est juste que toutes les classes du framework n'ont pas forcément été définies selon la même philosophie...