IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Macros et VBA Excel Discussion :

Table de données: Passer un Array à l'objet ListColumns [XL-2016]


Sujet :

Macros et VBA Excel

  1. #1
    Expert éminent
    Avatar de MarcelG
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2009
    Messages
    3 345
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2009
    Messages : 3 345
    Points : 6 900
    Points
    6 900
    Billets dans le blog
    7
    Par défaut Table de données: Passer un Array à l'objet ListColumns
    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.

    Bien Cordialement.

    Marcel

    Dernier billet:
    Suppression des doublons d'un tableau structuré, gestion d'un array

    Pas de messagerie personnelle pour vos questions, s'il vous plaît. La réponse peut servir aux autres membres. Merci.


  2. #2
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    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).

    Nom : 2021-03-04_194045.png
Affichages : 67
Taille : 8,8 Ko


    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.
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  3. #3
    Expert confirmé Avatar de Patrice740
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2007
    Messages
    2 457
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mars 2007
    Messages : 2 457
    Points : 5 611
    Points
    5 611
    Par défaut
    Bonjour Pierre,
    Citation Envoyé par Pierre Fauconnier Voir le message
    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).
    Cordialement,
    Patrice
    Personne ne peut détenir tout le savoir, c'est pour ça qu'on le partage.

    Pour dire merci, cliquer sur et quand la discussion est finie, penser à cliquer sur

  4. #4
    Expert éminent sénior

    Profil pro
    Conseil, Formation, Développement - Indépendant
    Inscrit en
    février 2010
    Messages
    7 352
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil, Formation, Développement - Indépendant

    Informations forums :
    Inscription : février 2010
    Messages : 7 352
    Points : 13 969
    Points
    13 969
    Par défaut
    Bonjour à tous

    Citation Envoyé par Patrice740 Voir le message
    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
    Chris
    PowerQuery existe depuis plus de 10 ans, est totalement intégré à Excel 2016 &+. Utilisez-le !

    Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson.
    Confucius

    ----------------------------------------------------------------------------------------------
    En cas de résolution, n'hésitez pas cliquer sur c'est toujours apprécié...

  5. #5
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    Salut Patrice,

    Citation Envoyé par Patrice740 Voir le message
    [...]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(1).



    Attention à ne pas associer la notion de tableau structuré à celle de plage nommée(2). 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.



    (1) 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.

    (2) 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.
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  6. #6
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    Citation Envoyé par Patrice740 Voir le message
    [...]
    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...

    Nom : 2021-03-05_070108.png
Affichages : 55
Taille : 20,1 Ko

    Nom : 2021-03-05_070439.png
Affichages : 53
Taille : 19,8 Ko


    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
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  7. #7
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    Citation Envoyé par Patrice740 Voir le message
    [...]
    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).

    Nom : 2021-03-05_075202.png
Affichages : 50
Taille : 9,6 Ko


    Nom : 2021-03-05_075546.png
Affichages : 50
Taille : 28,9 Ko


    Nom : 2021-03-05_075605.png
Affichages : 52
Taille : 16,1 Ko



    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

    Nom : 2021-03-05_080217.png
Affichages : 52
Taille : 14,9 Ko

    Nom : 2021-03-05_080552.png
Affichages : 50
Taille : 6,6 Ko
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  8. #8
    Expert éminent
    Avatar de MarcelG
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2009
    Messages
    3 345
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2009
    Messages : 3 345
    Points : 6 900
    Points
    6 900
    Billets dans le blog
    7
    Par défaut
    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.

    Bien Cordialement.

    Marcel

    Dernier billet:
    Suppression des doublons d'un tableau structuré, gestion d'un array

    Pas de messagerie personnelle pour vos questions, s'il vous plaît. La réponse peut servir aux autres membres. Merci.


  9. #9
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    Citation Envoyé par MarcelG Voir le message
    [...]
    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
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  10. #10
    Expert éminent
    Avatar de MarcelG
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2009
    Messages
    3 345
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2009
    Messages : 3 345
    Points : 6 900
    Points
    6 900
    Billets dans le blog
    7
    Par défaut
    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.

    Bien Cordialement.

    Marcel

    Dernier billet:
    Suppression des doublons d'un tableau structuré, gestion d'un array

    Pas de messagerie personnelle pour vos questions, s'il vous plaît. La réponse peut servir aux autres membres. Merci.


  11. #11
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    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.

    Citation Envoyé par MarcelG Voir le message
    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
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  12. #12
    Expert confirmé Avatar de Patrice740
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2007
    Messages
    2 457
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mars 2007
    Messages : 2 457
    Points : 5 611
    Points
    5 611
    Par défaut
    Bonjour,
    Citation Envoyé par Pierre Fauconnier Voir le message
    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.
    Cordialement,
    Patrice
    Personne ne peut détenir tout le savoir, c'est pour ça qu'on le partage.

    Pour dire merci, cliquer sur et quand la discussion est finie, penser à cliquer sur

  13. #13
    Expert éminent
    Avatar de MarcelG
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2009
    Messages
    3 345
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2009
    Messages : 3 345
    Points : 6 900
    Points
    6 900
    Billets dans le blog
    7
    Par défaut
    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.

    Bien Cordialement.

    Marcel

    Dernier billet:
    Suppression des doublons d'un tableau structuré, gestion d'un array

    Pas de messagerie personnelle pour vos questions, s'il vous plaît. La réponse peut servir aux autres membres. Merci.


  14. #14
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    Citation Envoyé par Patrice740 Voir le message
    Ç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).

    Citation Envoyé par Patrice740 Voir le message
    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?

    Citation Envoyé par Patrice740 Voir le message
    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.


    Citation Envoyé par Patrice740 Voir le message
    [...]
    Ç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.

    Nom : 2021-03-05_151819.png
Affichages : 39
Taille : 13,1 Ko


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

    Citation Envoyé par Patrice740 Voir le message
    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
    Nom : 2021-03-05_153032.png
Affichages : 37
Taille : 148,0 Ko
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  15. #15
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    Citation Envoyé par MarcelG Voir le message
    [...]
    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

    Citation Envoyé par MarcelG Voir le message
    [...]
    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)
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  16. #16
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    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à
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  17. #17
    Expert confirmé Avatar de Patrice740
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2007
    Messages
    2 457
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mars 2007
    Messages : 2 457
    Points : 5 611
    Points
    5 611
    Par défaut
    Citation Envoyé par Pierre Fauconnier Voir le message
    ...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é.
    Cordialement,
    Patrice
    Personne ne peut détenir tout le savoir, c'est pour ça qu'on le partage.

    Pour dire merci, cliquer sur et quand la discussion est finie, penser à cliquer sur

  18. #18
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    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
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  19. #19
    Expert éminent sénior

    Profil pro
    Conseil, Formation, Développement - Indépendant
    Inscrit en
    février 2010
    Messages
    7 352
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil, Formation, Développement - Indépendant

    Informations forums :
    Inscription : février 2010
    Messages : 7 352
    Points : 13 969
    Points
    13 969
    Par défaut
    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...
    Chris
    PowerQuery existe depuis plus de 10 ans, est totalement intégré à Excel 2016 &+. Utilisez-le !

    Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson.
    Confucius

    ----------------------------------------------------------------------------------------------
    En cas de résolution, n'hésitez pas cliquer sur c'est toujours apprécié...

  20. #20
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur chez EXCELLEZ.net
    Inscrit en
    novembre 2003
    Messages
    17 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur chez EXCELLEZ.net
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 17 198
    Points : 49 585
    Points
    49 585
    Billets dans le blog
    92
    Par défaut
    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

    Nom : 2021-03-05_193321.png
Affichages : 24
Taille : 7,2 Ko
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Données]Passer des données entre applet et Servlet
    Par CheryBen dans le forum Applets
    Réponses: 11
    Dernier message: 16/09/2005, 13h48
  2. Réponses: 1
    Dernier message: 27/07/2005, 11h47
  3. [cr 8.5] comment exploiter les données d'un "array"
    Par kikidrome dans le forum SAP Crystal Reports
    Réponses: 12
    Dernier message: 09/06/2005, 14h03
  4. Réponses: 9
    Dernier message: 07/10/2004, 19h41
  5. [QuickReport] Données d'une table et données calculées
    Par poufouille dans le forum Bases de données
    Réponses: 11
    Dernier message: 30/03/2004, 16h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo