Discussion :

[Salmander]

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 :

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

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.

ListBox.xlsm

[Pierre Fauconnier]

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?^*


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

Code :

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

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 :

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

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

[Salmander]

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

[Pierre Fauconnier]

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.



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:





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 :

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

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é).

[Pierre Fauconnier]

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 :

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

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:



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 :

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

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.




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 :

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

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