Discussion :

[MarcelG]

Bonsoir les amis,

(Désolé pour cette absence de réponse. Surbooké.)

Question (simple?)
Pourquoi VBA ne reconnait-il pas un array comme paramètre de l'objet ListColumns?

Précision préalable:
Les colonnes choisies sont disjointes.

Procédure appelante

Code :

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

1
2
3
Public Sub essai_colonnes()
Call visu_col(levisu:=True)
End Sub

Procédure appelée

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Public Sub visu_col(levisu As Boolean)
 
'https://stackoverflow.com/questions/45356240/vba-for-selecting-a-number-of-columns-in-an-excel-table
'https://www.mrexcel.com/board/threads/select-3-of-6-list-columns.568383/
 
Dim liste_colonnes As Variant, lacol As Variant
liste_colonnes = Array("Répertoire 1", "Répertoire 3", "Répertoire 4", "Répertoire 5", "Répertoire 6", "Répertoire 7", "Type de fichier", "Nom du fichier")
 
For Each lacol In liste_colonnes
        Worksheets("Reporting").ListObjects("T_Liste").ListColumns(lacol).Range.EntireColumn.Hidden = Not levisu
Next lacol
 
End Sub

Ce code est effectif.
Néanmoins (comme dirait Cyrano ), j'aurais souhaité ne pas utiliser de boucle.

Mais cette ligne

Code :

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

Worksheets("Reporting").ListObjects("T_Liste").ListColumns(liste_colonnes).Range.EntireColumn.Hidden = Not levisu

génère une erreur
(Idem si j'utilise Evaluate).

9 - L'indice n'appartient pas à la sélection.

Sauf erreur, il est possible de paramétrer l'objet Worksheets par un array.

Pourquoi pas ListColumns?

Moi qui parle anglais comme une vache italienne, j'ai consulté les 2 espaces figurant dans mon code, MrExcel et stackoverfow (qui peuvent être précieux par ailleurs )
Pour ma part, je trouve la méthode Union un peu lourde

Par avance, merci pour vos éclairantes lumières.

[Pierre Fauconnier]

Salut Marcel,

Perso, ça ne me gêne pas qu'il faille pratiquer de la sorte. Si tu te crées une procédure générique, la boucle est quasi instantanée (sauf à avoir 16000 colonnes).




Au passage, je n'aime pas trop le Worksheets("Reporting").ListObjects("T_Liste").ListColumns(lacol).Range.EntireColumn.Hidden = Not levisu et lui préfère Range("T_Liste").ListObject.ListColumns(lacol).Range.EntireColumn.Hidden = Not levisu pour découpler la ligne du nom de l'onglet de la feuille.

[Patrice740]

Bonjour Pierre,

Au passage, je n'aime pas trop le Worksheets("Reporting").ListObjects("T_Liste").ListColumns(lacol).Range.EntireColumn.Hidden = Not levisu et lui préfère Range("T_Liste").ListObject.ListColumns(lacol).Range.EntireColumn.Hidden = Not levisu pour découpler la ligne du nom de l'onglet de la feuille.

La première syntaxe est tout à fait canonique, le tableau appartient à la feuille, et cette syntaxe permet de définir un tableau situé sur un autre classeur. C'est à mon avis celle qu'il faut privilégier.
Je trouve la seconde plutôt cavalière, on peut se demander qu'est-ce que ce Range ? Pourquoi ça fonctionne ?
En absence de précision du parent, Range est sensé appartenir à Activesheet mais pas dans ce cas !
Avec une plage nommée de portée classeur, Range("MaPlage") c'est pareil,
mais il y a une syntaxe canonique : ActiveWorkbook.Names("MaPlage").RefersToRange

Edit : c'est probablement pour ça que ça fonctionne (parce que ça fonctionne avec une plage nommée).

[78chris]

Bonjour à tous

La première syntaxe est tout à fait canonique, le tableau appartient à la feuille, et cette syntaxe permet de définir un tableau situé sur un autre classeur. C'est à mon avis celle qu'il faut privilégier.
Je trouve la seconde plutôt cavalière, on peut se demander qu'est-ce que ce Range ? Pourquoi ça fonctionne ?
En absence de précision du parent, Range est sensé appartenir à Activesheet mais pas dans ce cas

Le nom d'un tableau est unique pour le classeur donc la Syntaxe Range("NomTableau").ListObject reste la plus efficace

Ce n'est en aucun cas ActiveSheet par défaut

[Pierre Fauconnier]

Salut Patrice,

[...]cette syntaxe permet de définir un tableau situé sur un autre classeur.[...]

Non, sans parentalité sur l'objet Worksheets, on reste dans le classeur actif, comme avec la syntaxe que je donne. Si on parlait d'aller chercher dans un autre classeur (ce qui n'est pas demandé ici), alors j'aurais donné une autre réponse que celle que j'ai fournie, mais je n'aurais de toute façon pas utilisé cette syntaxe, privilégiant alors une fonction qui ne plantera pas le code en cas de problème (feuille mal nommée, tableau mal nommé...)

La syntaxe Worksheets("Reporting").ListObjects(...) lie ton code à la feuille. Si tu renommes la feuille ou que tu déplaces le tableau sur une autre feuille, ton code plantera. La syntaxe Range("T_Liste").ListObject... découple le tableau de la feuille, te dispensant de savoir où il se trouve dans le classeur. Ton code est alors un peu moins lié à la structure de ton classeur. C'est tout l'intérêt de la seconde syntaxe

Pour ce qui est d'un tableau se trouvant dans un autre classeur, j'ai résolu le problème par une fonction générique qui me renvoie le listobject en précisant son nom et éventuellement le classeur où il se trouve, afin d'avoir un code identique pour pointer vers un listobject quel que soit son emplacement dans mon environnement Excel actif⁽¹⁾.



Attention à ne pas associer la notion de tableau structuré à celle de plage nommée⁽²⁾. Un tableau structuré n'est pas une plage nommée et ne contient pas de plage nommée, même si on retrouve les deux concepts dans le gestionnaire de noms. Les tableaux structurés ne sont d'ailleurs pas repris dans la collection Names d'un classeur. Il faut noter qu'à la différence d'un tableau structuré dont le nom est unique dans le classeur, il peut y avoir plusieurs "plages nommées" ayant des noms identiques mais pointant évidemment vers des feuilles différentes, et même des zones différentes sur les feuilles. Donc on ne peut pas se priver de la parentalité d'une plage nommée dans tous les cas, alors que je ne vois pas de cas où la parentalité d'un tableau structuré aurait de l'importance.



⁽¹⁾ En fait, j'ai créé un "superlistobject" qui englobe le listobject et lui donne des méthodes et propriétés additionnelles qui font défaut sur le listobject natif d'Excel et c'est avec cet objet que je travaille dans mes classeurs pro. Faudra que je prenne le temps de finir le tuto que j'ai commencé sur le sujet.

⁽²⁾ Plage nommée est pour moi un "abus de langage" car en fait, ça n'existe pas une "plage nommée". Et cet abus de langage masque une réalité bien utile. En réalité, ce qui existe dans Excel, ce sont des formules nommées qui pointent éventuellement vers une plage, c'est-à-dire dont le résultat est une plage. Mais on peut créer des "vraies" formules nommées, utilisant notamment des références relatives, et ce concept est parfois bien utile pour raccourcir certaines formules qui utilisent du code à répétition. La fonction Lambda qui va voir le jour s'inscrit d'ailleurs dans la suite logique de ce concept de formule nommée.

[Pierre Fauconnier]

[...]
Je trouve la seconde plutôt cavalière, on peut se demander qu'est-ce que ce Range ? Pourquoi ça fonctionne ?[...]

Si on est habitué aux références structurées en Excel, on ne devrait pas être surpris que "ça fonctionne". J'ai dans de nombreuses réponses sur le forum illustré l'utilisation des références structurées en VBA, que ce soit vers le tableau en entier ou vers une de ces parties.

Les deux illustrations suivantes illustrent que le code reste identique quelle que soit la feuille qui supporte le tableau structuré, quelle que soit la place de celui-ci dans la feuille et quel que soit l'ordre des colonnes dans le tableau...






L'utilisation des références structurées en VBA, pointant ou pas vers le listobject, est à mon avis à privilégier pour une plus grande souplesse et une maintenabilité accrue du code

[Pierre Fauconnier]

[...]
Avec une plage nommée de portée classeur, Range("MaPlage") c'est pareil,
mais il y a une syntaxe canonique : ActiveWorkbook.Names("MaPlage").RefersToRange[...]

Ce n'est exact que si tu as une plage nommée de portée classeur et pas de plage éponyme de portée feuille.

Voici un classeur avec trois plages nommées éponymes, une de classeur et deux de feuille. On va voir dans le code que Range("test") et Names("Test").RefersToRange ne pointent pas toujours vers la même plage. Et l'on voit également que Range("Test") pointe vers la feuille active si elle contient une plage Test et vers la plage Test de portée classeur si elle ne contient pas de plage Test (dernière illustration avec Feuil3 active).











Méfiance donc avec les plages nommées et leur portée, car le même code pointe vers des plages différentes en fonction du contexte.




On notera au passage que RefersToRange plante si la formule nommée ne pointe pas vers une plage

[MarcelG]

Bonjour à tous,

Merci pour ces échanges constructifs.

Pour ma part, je reste attaché à la déclinaison explicite des objets, quels qu'ils soient (un classeur, une feuille, un objet tableau, un objet colonne de tableau...).

Après tout, à chacun sa sensibilité.
L'essentiel restant la rigueur.

Bon week-end à vous, Bon week-end au forum.

A bientôt, j'espère.

[Pierre Fauconnier]

[...]
Après tout, à chacun sa sensibilité.[...]

Ce n'est pas une question de sensibilité, mais une question de bonnes pratiques, ces dernières amenant à réduire les risques d'erreurs et de plantage. Mentionner la parentalité d'un listobject dont on connaît le nom ne sert strictement à rien dans aucun cas de figure et générera des erreurs en cas de déplacement de l'objet sur une autre feuille ou en cas de renommage de la feuille.

Au passage, pointer vers une feuille du classeur actif via Worksheets("Reporting") n'a pour moi pas beaucoup de sens, et je préfère dans ce cas utiliser le codename de la feuille, tel qu'expliqué dans ce billet de Philippe.


je ne mentionne pas ceci pour les participants actuels à cette discussion (après tout, vous codez comme vous voulez) mais pour le lecteur qui aura envie d'améliorer l'écriture de son code

[MarcelG]

Coder tout de go

Range("montablo[lacolonne]")

est, pour moi simple mortel, moins évocateur que la déclinaison explicite des objets.
Au demeurant, je ne saurais être présomptueux en remettant en cause ce que tu reportes. Bien entendu.

Pour le reste

pointer vers une feuille du classeur actif via Worksheets("Reporting") n'a pour moi pas beaucoup de sens, et je préfère dans ce cas utiliser le codename de la feuille, tel qu'expliqué dans ce billet de Philippe.

Merci pour ce lien. Je vais le consulter avec intérêt, et tenter de m'y appliquer au plus vite pour mes prochains développements.
(Quant aux anciens... J'ai récemment accédé à l'un de mes codes, datant de 2015, où je renommais des plages de données avec End(xlUp) pour les utiliser dans mes formulations. Le temps me devient compté à grands pas pour y revenir...)

Preuve en est que toute discussion, au sens propre du terme, est toujours profitable.

[Pierre Fauconnier]

Marcel,

C'est parce que c'est une discussion que tu as initiée que je me suis entêté à prêcher la bonne parole, car je sais que nous pouvons discuter et que tu ne prends pas pour attaques personnelles mes critiques du code, qui se veulent toujours constructives.

Coder tout de go

Range("montablo[lacolonne]")

est, pour moi simple mortel, moins évocateur que la déclinaison explicite des objets.[...]

On pourrait croire que Range("montablo[lacolonne]") revient au même que MaFeuille.Listobjects("montablo").listcolumns("lacolonne").databodyrange au delà du fait que la seconde est tout de même plus longue que la première), mais dans le cas où le tableau est vide, la seconde syntaxe plantera car le databodyrange sera Nothing. A nouveau, l'utilisation de la référence structurée au sein d'un objet Range ("un peu" comme une plage nommée) permet, outre une économie de code, de manipuler la colonne alors même que le tableau est vide (ne serait-ce que pour la redimensionner et lui pousser le contenu d'un array).

Ca ne veut pas dire que l'utilisation explicite d'un listcolumn n'est pas intéressante, j'ai d'ailleurs déjà montré des codes où j'utilise l'index d'un listcolumn pour savoir dans quelle cellule de la plage d'une ligne d'un tableau je dois pousser ma valeur.

Chaque type d'écriture a donc son intérêt et c'est pour moi bien moins une question de style, de préférence ou d'habitude que de recherche du code qui donnera le meilleur rapport fiabilité/concision.


Au delà, j'invite ceux qui prônent la mention de la parentalité "à tous coups" à revoir leur code car alors écrire
Worksheets("Reporting").ListObjects("T_Liste").ListColumns("Macolonne").Range.EntireColumn.Hidden = Not levisu n'est pas correct. Il faut être cohérent et écrire
Application.Workbooks("MonClasseur").Worksheets("Reporting").ListObjects("T_Liste").ListColumns(l"Macolonne").Range.EntireColumn.Hidden = Not levisu.

Perso, pour le classeur actif, je me contente de
range("t_Liste[MaColonne]").EntireColum.Hidden = Not levisu

[Patrice740]

Bonjour,

Si on est habitué aux références structurées en Excel, on ne devrait pas être surpris que "ça fonctionne".

Je ne suis pas surpris par le fait que ça fonctionne, et c'est bien évidemment un avantage de pouvoir s'affranchir de la feuille pour identifier un tableau.

Je suis surpris qu'on emploie le mot Range alors que ça ne correspond pas à un range (pas toujours).
C'est cette syntaxe avec le mot Range que je trouve cavalière, ceci d'autant plus qu'il n'est pas possible de préciser le parent de ce Range sans perdre l'avantage qu'il procure.
Ça ajoute l’inconvénient de s'appliquer uniquement au classeur actif.

Comme Marcel, que je salue, je reste attaché à la définition Explicite des objets.

Je pense que les objets Names et Name auraient été bien plus appropriés pour identifier un LO. Il aurait suffit d'inclure les noms des tableaux dans Names.
Ceci d'autant plus, que les noms de LO sont uniques et qu'il apparaissent dans la liste des noms sous Excel, mais malheureusement dans pas dans VBA.
Va savoir pourquoi ?
Ça date d'Excel 2007 avec l'apparition des noms de plage de portée feuille et des ListObjects.

[MarcelG]

C'est parce que c'est une discussion que tu as initiée que je me suis entêté à prêcher la bonne parole, car je sais que nous pouvons discuter et que tu ne prends pas pour attaques personnelles mes critiques du code, qui se veulent toujours constructives.

Oserais-je dire le contraire?!

Au delà, j'invite ceux qui prônent la mention de la parentalité "à tous coups" à revoir leur code car alors écrire
Worksheets("Reporting").ListObjects("T_Liste").ListColumns(lacol).Range.EntireColumn.Hidden = Not levisu n'est pas correct. Il faut être cohérent et écrire
Application.Workbooks("MonClasseur").Worksheets("Reporting").ListObjects("T_Liste").ListColumns(lacol).Range.EntireColumn.Hidden = Not levisu.

Oui, Pierre.

Mais si, comme tu l'écris, on se base sur

Perso, pour le classeur actif, je me contente de

J'ai bien lu "classeur actif"
Mon écriture reste valable, et ce d'autant que dans mes codes, "lebook" (This ou un autre) est le plus souvent utilisé dans un bloc With.

Maintenant, je souhaiterais que cette discussion ne prenne pas un mauvais tournant comme cela semble être le cas.
Alors, s'il te plaît, restons-en là.
Il en va de l'intérêt du Forum, comme de nous-même.

Pour une simple question initiale...

Avec regrets.

[Pierre Fauconnier]

Ça date d'Excel 2007 avec l'apparition des noms de plage de portée feuille et des ListObjects.

Le ListObject est apparu dans la 2003 (bien caché, on le créait via le menu Données et dans Excel, ça s'appelait une liste de données => d'où le raccourci CTRL+L). Les "plages nommées" de portée feuille existaient avant la 2007. D'ailleurs, depuis "toujours", lorsque l'on crée une copie d'une feuille qui contient des "plages nommées", de portée classeur ou de feuille, Excel crée de nouvelles plages nommées avec portée de feuille pour "copier" les plages nommées de la source. Il faut d'ailleurs noter que l'on peut pointer vers une plage de portée feuille d'une autre feuille en la préfixant du nom de la feuille (pour la différencier, notamment, d'une plage éponyme de portée classeur).

Comme Marcel, que je salue, je reste attaché à la définition Explicite des objets.

Tu as vu mon clin d'oeil sur la parentalité explicite dans ma réponse précédente?

Je suis surpris qu'on emploie le mot Range alors que ça ne correspond pas à un range (pas toujours).

Je ne comprends pas ce que tu veux dire car une référence structurée correspond TOUJOURS à un range comme c'est le cas en Excel, à la différence du Databodyrange qui est parfois Nothing.

[...]
Ça ajoute l’inconvénient de s'appliquer uniquement au classeur actif.[...]

Le code donné par Marcel au départ utilise le classeur actif puisque la parentalité de Worksheets("Reporting") n'est pas définie. On ne fait jamais que remonter le pseudo-problème d'un niveau, mais ton argument de "limité au classeur actif" ne tient pas avec le code proposé par Marcel et que tu préfères à celui qui utilise le range.

Pour le reste, on peut atteindre le listobject de n'importe quelle cellule qui fait partie d'un tableau structuré par sa propriété ListObject qui sera Nothing si elle hors tableau structuré. Ce n'est que par facilité que l'on utilise la référence structurée et pour découpler le code de la position du tableau sur la feuille, mais si on regarde l'illustration suivante, on voit que l'on peut atteindre le tableau t_Contacts de n'importe quelle cellule de la plage qui contient le tableau, en ce compris son entête.




Par contre, pour une raison que j'ignore, on ne sait pas y accéder par la la référence T_Contacts[#Totals]...

ceci d'autant plus qu'il n'est pas possible de préciser le parent de ce Range sans perdre l'avantage qu'il procure.
Ça ajoute l’inconvénient de s'appliquer uniquement au classeur actif.

Je suppose que tu veux dire que c'est dommage que le tableau soit rattaché à une feuille et pas au classeur. Si c'est cela, je suis d'accord avec toi mais, comme dit plus haut, une fonction générique renvoyant un listobject sur base de son nom permet de pallier ce défaut à moindres frais:

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
Function getListObject(Name As String, Optional wb As Workbook) As ListObject
  Dim sh As Worksheet
  Dim lo As ListObject
  Dim i As Long: i = 1
  Dim j As Long
 
 
  If wb Is Nothing Then Set wb = ActiveWorkbook
  Do While i <= wb.Worksheets.Count And getListObject Is Nothing
    j = 1
    Do While j <= wb.Worksheets(i).ListObjects.Count And getListObject Is Nothing
      If VBA.StrComp(Name, wb.Worksheets(i).ListObjects(j).Name, vbTextCompare) = 0 Then _
        Set getListObject = wb.Worksheets(i).ListObjects(j)
      j = j + 1
    Loop
    i = i + 1
  Loop
End Function

[Pierre Fauconnier]

[...]
Maintenant, je souhaiterais que cette discussion ne prenne pas un mauvais tournant comme cela semble être le cas.
Alors, s'il te plaît, restons-en là.
Il en va de l'intérêt du Forum, comme de nous-même.

Pour une simple question initiale...

Avec regrets.

Perso, je n'ai pas l'impression qu'elle tourne mal (mais chacun sa sensibilité ). Je mentionne que les syntaxes proposées ne se valent pas et ne pointent pas toujours vers les mêmes objets. Ca me semble être de bonne guerre sur un forum technique

[...]
Au demeurant, je ne saurais être présomptueux en remettant en cause ce que tu reportes. Bien entendu.[...]

Tu peux mettre en cause ce que j'énonce sans être présomptueux, tu sais. On discute entre experts ici, et je suis prêt à faire mienne toute pratique mentionnée dans une discussion que je jugerais meilleure que la mienne. C'est comme cela que j'ai toujours progressé dans mon utilisation d'Excel, du VBA et de la programmation en général, et c'est pour cela que j'essaie de diffuser ce que je pense être les meilleures pratiques (que je n'ai pas inventées, cfr ma signature)

[Pierre Fauconnier]

Pour terminer sur la parentalité....

Si l'on voulait être puriste, on devrait alors définir la parentalité des variables, des procédures et fonctions ainsi que de tous les objets que l'on utilise car VBA travaille "au plus près" et lorsque l'on utilise une variable, on devrait s'assurer de voir où le VBA va la chercher. Je n'ose imaginer comme le code serait lourd à écrire et à lire. J'ai d'ailleurs déjà mentionné cela lorsque je fustigeais l'utilisation de la syntaxe [A65000] en montrant qu'on pouvait avoir des soucis avec cette syntaxe. Je pourrais avoir des variables, des procédures et fonctions de noms identiques dans différentes parties de mon code et il me faudrait alors préciser cette parentalité.

L'ordre de recherche du parent dans les bibliothèques est celui défini dans la fenêtre des références et on pourrait avoir des surprises étonnantes lorsque deux bibliothèques utilisent des objets différents de même nom. La encore, la parentalité devrait être précisée.


Mais tout dépend du projet que l'on développe et, pour un code qui tourne uniquement avec le classeur actif, je ne vois pas l'intérêt d'alourdir le code. Si je travaille dans le classeur actif, j'utilise Range("t_Contacts") dans 95% des cas et Range("t_Contacts").Listobject si je dois manipuler le Listobject. Et lorsque mon projet dépasse le cadre du classeur actif, j'utilise des fonctions qui me ramènent les objets des autres classeurs que je manipule. Cela me semble être une démarche pragmatique. Or, le code proposé par Marcel en entame de la discussion est limité de facto au classeur actif par l'utilisation non préfixée de Worksheets("Reporting")...

Voilà voilà

[Patrice740]

...Je ne comprends pas ce que tu veux dire ....
Je suppose que tu veux dire que c'est dommage que le tableau soit rattaché à une feuille et pas au classeur.

Effectivement on ne se comprend pas.

Il est parfaitement logique que le tableau structuré soit rattaché à une feuille et pas au classeur.
Il ne peut pas être rattaché au classeur car il dépend de la feuille qui le supporte, si je supprime la feuille, le tableau disparaît.

Vu que le nom de chaque tableau d'un classeur est unique, je trouve qu'il est parfaitement légitime de pouvoir y accéder simplement en référence au classeur.
Et donc sans faire référence à la feuille et sans employer le mot Range qui est une élément d'une feuille et pas un élément de classeur.
Ce que je veux veux dire donc, c'est que je trouve la syntaxe Range("montablo") inappropriée.
Ça s'applique aussi aux plages nommées de portée classeur dont l'unicité du nom englobe ceux des tableaux.
Un très mauvais choix de Microsoft !!! Effectivement avant Excel 2003.

J'aurais trouvé beaucoup plus logique de pouvoir y accéder via un élément de classeur, par exemple via Names("montablo") qui offre le possibilité de définition explicite du classeur, contrairement à Range. Il aurait suffit que les noms des tableaux apparaissent dans Names comme c'est le cas dans Excel.

EDIT : Quand à la parentalité, je ne suis pas un adepte de la parentalité totale, mais d'un niveau de parentalité suffisant. Je trouve anormal d'utiliser .Select ou .Activate pour s'affranchir de la parentalité.

[Pierre Fauconnier]

Merci Patrice pour ces précisions

Je suis tout à fait d'accord qu'il aurait été utile, et somme toute logique, de pouvoir accéder aux listobjects directement via un propriété du classeur, et pourquoi pas via la collection Names, puisque l'on retrouve les tableaux structurés dans le gestionnaire de noms, et je pense donc que nous nous retrouvons sur ce point. Ca aurait facilité grandement la manipulation des listobjects d'un autre classeur. Je pense malheureusement que Microsoft ne reviendra pas là-dessus.

Sur la parentalité, j'ai un peu forcé le trait, je reconnais , mais je trouve très utile que la discussion ait débordé sur le sujet car beaucoup de problèmes sur le forum surviennent à cause d'une problème de parentalité mal géré, voire pas géré du tout. J'espère que toute la discussion servira à nos lecteurs à améliorer leur compréhension de l'objet Excel.

Par contre, pour le classeur actif, et peut-être parce qu'avant les tableaux structurés, je travaillais beaucoup avec des plages nommées (créées notamment avec DECALER), je trouve très confortable de pouvoir manipuler les références structurées (<> listobject!!) grâce à des objets Range, puisqu'elles pointent vers des plages, et pas étrange du tout que l'on ait ajouté la propriété ListObject à un objet Range.

Merci en tout cas pour ces échanges

[78chris]

RE à tous

Le listobject est très proche dans sa logique d'une table de BD

Il aurait fallu créé un objet totalement nouveau mais d'une part cela aurait sans doute été compliqué et je doute que, quand cela a été ajouté à 2003, Microsoft savait clairement où ils allaient...

Donc on a quelque chose d'un peu hybride...

[Pierre Fauconnier]

Chris,

Je pense que ce n'était pas bien compliqué pour Microsoft de créer une propriété du workbook qui renvoie une collection des listobjects

Ce code, écrit en 2 minutes et placé dans le module du workbook, le fait et permet de récupérer un listobject du classeur par son nom. Ca aurait déjà rendu bien des services, non?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Property Get ListObjects() As Collection
  Dim sh As Worksheet
  Dim lo As ListObject
 
  Set ListObjects = New Collection
  For Each sh In Me.Worksheets
    For Each lo In sh.ListObjects
      ListObjects.Add lo, lo.Name
    Next
  Next
End Property