Ôter les crochets []

Bonjour, après avoir lu le billet d’humeur de l’excellent Pierre Fauconnier :
VBA-Excel: Notation raccourcie d'une plage, une fausse bonne idée! - Blogs - Forum du club des développeurs et IT Pro (developpez.net)

J’ai compris l’erreur que je commettais depuis longtemps.
Je tiens à préciser que je ne fais pas partie des initiés mais plutôt des ploucs et que j’utilisais cette syntaxe parce que visuellement cela me permettait de repérer mes shapes et plages plus facilement.

J’ai commencé l’épurage de mes scripts mais il me reste un point sur lequel j’achoppe : les ListBox.

Je sèche sur ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Sub PropLBX()   Dim i As Byte Dim NoLgn As Byte Dim NbLgn As Byte Dim ValLgn As String   NoLgn = [ListBox].ListIndex 'N° de ligne active NbLgn = [ListBox].ListCount 'Nombre de lignes   For i = 1 To [ListBox].ListCount 'Selectionne chaque valeur une a une   [ListBox].ListIndex = i 'Selectionne une ligne ValLgn = [ListBox].List([ListBox].ListIndex) ' Valeur de la ligne active   Next   End Sub

---

Si quelqu’un peu me donner une direction pour corriger, je lui en serais plus que reconnaissant.

Pièce jointe 600846

Salut.

Ton code avec crochets fonctionne sans soucis. Mais... Si j'enlève les crochets, ça bugue => normal. Je remets les crochets => ça continue à buguer. Rigolo, non?^* :koi:


Perso, voici comment j'adresse un contrôle de formulaire placé sur une feuille:

Code:

---

NoLgn = Shapes("Listbox").OLEFormat.Object.ListIndex

---

Pour éviter la répétition de tout l'adressage de l'objet sur chaque ligne, tu peux le mettre en variable en début de code et le supprimer à la fin.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Sub PropLBX()   Dim i As Byte Dim NoLgn As Byte Dim NbLgn As Byte Dim ValLgn As String Dim lb As Object   Set lb = Shapes("Listbox").OLEFormat.Object NoLgn = lb.ListIndex 'N° de ligne active NbLgn = lb.ListCount 'Nombre de lignes   For i = 1 To lb.ListCount 'Selectionne chaque valeur une a une lb.ListIndex = i 'Selectionne une ligne ValLgn = lb.List(lb.ListIndex) ' Valeur de la ligne active Next   Set lb = Nothing End Sub

---

^* Je tire comme conclusion de cette bizarrerie une raison supplémentaire de ne pas utiliser cette notation ;)

Merci beaucoup de t’être occupé de mon cas.
C’est absolument parfait.

Maintenant il faut que j’apprenne à me servir de l’instruction : Set

Juste deux mots sur le Set

Set sert à affecter une valeur à une variable de type Objet. VBA qui n'est pas un langage totalement orienté objet et qui est en plus très permissif, utilise des variables primaires et des variables Objet. Les variables primaires sont les string, les numériques (single, double, long, integer, byte), les booléens (True et False), les dates (date et heure), ainsi que les types personnalisés (Type... End Type). Les variables primaires sont affectées sans utiliser Set. Pour toutes les autres variables, tu dois utiliser Set pour indiquer à VBA que tu prends bien l'objet et non sa valeur par défaut, qui pourrait être une valeur d'un type primaire.

Si tu regardes l'illustration suivante, tu vois que le mot set revêt toute son importance puisque, alors que A et B sont déclarés sans type (=> ils sont alors de type Variant), a reçoit la valeur de la cellule alors que b reçoit la cellule en tant qu'objet. Omettre le Set devant b ne lèverait pas d'erreur mais tu ne récupèrerais pas l'objet.

Pièce jointe 600897

C'est pourquoi, lorsque l'on n'est pas certain du type de la valeur que l'on va récupérer, il est préférable de typer en Variant pour les types primaires (ou de ne pas typer ce qui revient au même) et de typer en Object une variable qui doit recevoir un objet lorsque l'on n'est pas certain du type de l'objet que l'on va récupérer... Ainsi, si on oublie le Set, on plantera à la compilation:

Pièce jointe 600898

Pièce jointe 600899

Pour lever toute ambiguïté, je préfère ne pas utiliser la propriété par défaut et la spécifier dans mon code de manière explicite:

Code:

---

1 2 3 4 5 6 7

Sub Test() Dim a Dim b As Object   a = Range("a1").Value Set b = Range("a1") End Sub

---

Il est de toute façon préférable selon mes bonnes pratiques de:

• toujours déclarer les variables, et forcer le VBE à nous imposer cette contrainte;
• typer autant que possible les variables que l'on utilise;
• ne pas utiliser les propriétés par défaut mais les citer de manière explicite^(*).

^(*) Cela rejoint d'ailleurs l'esprit du billet que tu as cité précédemment. J'attache de l'importance à ce que mon code soit lisible et compréhensible même par une personne ne connaissant pas les finesses du langage. Je trouve donc qu'il est plus utile de lui permettre de comprendre directement que l'on affecte la valeur de la cellule (a = Range("a1").Value) plutôt que de lui laisser supposer que Range("a1") vers une variable "non object" va transférer la propriété .Value (et pas .Text ou .Value2 ou n'importe quelle autre propriété).

Encore un petit truc sur le Set et la propriété par défaut (d'un objet Range, dans ce cas-ci) ;)

Lorsque l'on affecte un objet à une propriété d'un autre objet, on a deux choix, selon la façon dont la classe a été écrite, et on va voir que le code peut vraiment être ambigu.


Voici le code d'une classe nommée Perso. Elle est très simple puisqu'elle contient deux propriétés publiques autoimplémentées. Ce code se place dans un module de classe nommé Perso.

Code:

---

1 2 3 4

Option Explicit   Public Content As Variant Public Range As Range

---

Si je veux manipuler un objet issu de cette classe, je vais devoir mettre un Set sur la ligne d'affectation de la propriété Range de mon objet. Si j'utilise la propriété par défaut de Range("a1") pour la propriété Value de l'objet myPerso, il n'y a pas trop d'ambiguïté puisque pour affecter la propriété Range de l'objet, je dois utiliser Set:
Pièce jointe 600946


Si maintenant je crée la propriété Range de mon objet avec un Setter, le code à l'intérieur de la classe va devoir utiliser Set pour affecter la valeur de la propriété publique à la variable privée.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

Option Explicit   Public Content As Variant Private mRange As Range   Property Let Range(Value As Range) Set mRange = Value End Property   Property Get Range() As Range Set Range = mRange End Property

---

Du coup, comme il est déjà mis dans la classe, je ne peux pas le remettre lors de l'affectation sous peine de lever une erreur. Le code qui utilise un objet de cette classe va créer une ambiguïté puisque l'on va voir deux lignes identiques, la première affectant la valeur de A1 et la seconde affectant la cellule A1 en tant qu'objet.

Pièce jointe 600947


C'est pour lever cette ambiguïté que je préconise de toujours utiliser le nom de la propriété, même lorsque l'on manipule la propriété par défaut:

Code:

---

1 2 3 4 5 6 7 8

Sub Test() Dim myPerso As Perso   Set myPerso = New Perso myPerso.Content = Range("a1").Value myPerso.Range = Range("a1") Debug.Print myPerso.Range.Address End Sub

---