Références absolues des cellules? Je ne parle pas des références "$" ici

Bonjour,

Je souhaitais savoir s'il existe des références absolues des cellules/lignes/colonnes interne à Excel, qu'on ne voit pas sur les feuilles mais qu'excel connaît, qui pourraient être exploitées en VBA et permettraient de suivre les cellules lors de leurs déplacements.

Par exemple, si je supprime la ligne 2, la cellule B4 devient B3, et pour l'appeler depuis VBA il faut l'appeler B4 avant suppression, B3 ensuite. Néanmoins, si on créé un nom pour la plage B4 (par exemple "TRUC"), quand on supprime la ligne 2, la plage TRUC se déplace de B4 en B3, et on peut la suivre, on sait que c'est TRUC.

Donc ma question : Existe-il dans VBA une manière d'identifier une cellule/ligne/colonne, comme on le fait avec les plages nommées, de façon qu'une cellule/ligne/colonne lors de son déplacement garde cet ID, sans avoir à créer des plages nommées (pour ne pas polluer ma liste des plages nommées avec 1000000 de nom pour 1000000 de cellules)?

Je n'ai rien trouvé sur le sujet, d'autant que quelque soit le mot-clé que j'utilise je tombe sur le sujet des B4 vs $B$4, qui n'est pas ce qui m'intéresse.

La question se pose principalement pour suivre avec VBA les opérations de suppression, déplacement, copies, etc, que ne sont pas identifiables en VBA si je ne me trompe pas (on peut identifier la plage concernée dans Workbook_SheetChange mais pas savoir si c'est une suppression, déplacement, etc), et notamment si plusieurs opérations manuelles sont faites à la suite, savoir où une cellule identifiée initialement se retrouve à la fin.

Merci d'avance pour votre aide

Bonjour

Une bonne partie est résolue par l'utilisation de tableaux structurés et le code qui va avec

Cela suit le déplacement du tableau, y compris sur un autre onglet, connait son nombre de lignes et de colonnes et peut retrouver l'emplacement de la colonne si on réordonne les colonnes du tableau

Mais cela ne descend pas au niveau d'un ID ligne ni cellule et le renommage d'une colonne n'est pas pisté

Bonsoir,

Votre préoccupation est tout à fait légitime et c'est bien pourquoi il existe :

1- le gestionnaire de noms (menu Formules) permettant d'affecter un nom à une cellule ou à une plage de cellules, nom qui correspond à une référence absolue,

2- les tableaux structurés permettant un code invariant et parlant en cas d'insertion de lignes/colonnes ou de déplacement du tableau

Bonjour,

En complément de ce qui a déjà été dit, il me semble que c'est ici qu'on doit parler de la colonne iD :

C'est à partir de cette clef unique qu'on place généralement en première colonne qu'on sait reconnaitre une référence quelle que soit sa position dans le tableau.

l'iD est aux enregistrements en général, ce qu'est le N° de sécurité sociale par rapport aux individus. C'est la raison pour laquelle on recommande toujours indexer les bases de données.

A+

Merci à tous pour vos réponses! Je vais regarder du côté des tableaux structurés, cela semble répondre à mon besoin. J'ai surtout besoin de suivre les lignes plutôt que les colonnes, je suis déjà les colonnes par des plages nommées, les lignes par contre sont trop nombreuses.

Je regarde ça et reviendrai ici si pour dire si ça a répondu ou pas.

Merci encore!

Bon, je n'arrive pas à franchir la première étape d'utilisation de tableau structuré, j'ai pourtant fait tout comme sur les tutos. Voici l'erreur que j'obtiens ci-dessous. le Range "Personnes" est une plage nommée que j'ai créé sur une des feuilles de 3 colonnes et 5 lignes. Ca a l'air trivial, mais je ne vois pas l'erreur.

Autre question, les tutos semblent dire qu'on peut facilement suivre une colonne dans un tableau structuré lors de son déplacement, et j'aurais plutôt besoin de suivre le déplacement des lignes. La propriété "Nom" des listcolumns semble permettre le suivi des colonnes (bien que je n'ai pas encore pu tester, vu le bug ci-dessus), mais je n'ai rien vu quand à une propriété "nom" de listrows? Est-ce possible de suivre les lignes lors de leur déplacement comme les colonnes?

Bonjour,

Nos 2 experts n'étant pas connectés à l'instant, je me permets de prendre le relai temporairement.

Avec l'utilisation des listobjects, tu peux laisser tomber le nommage manuel de tes plages. Dans le range ici, Excel attend le nom de la feuille.

Bonjour à tous

Il ne faut pas créer une plage nommée mais juste remplacer le nom automatique de type Tableau1 par Personnes

Inutile de préciser le nom de la feuille : ce qui permet de déplacer le tableau sans qu'Excel le perde de vue

A noter que listrow est un ligne de données. Le compte est à 0 tant qu'il n'y a pas de valeur sous la ligne de titre

78chris a écrit :

Mais cela ne descend pas au niveau d'un ID ligne ni cellule et le renommage d'une colonne n'est pas pisté

J'avais bien précisé que cela ne suivait pas les lignes et encore moins les cellules unitaire.

Le seul moyen de pister une ligne est une colonne d'ID

Bonjour,

Chris :

Le seul moyen de pister une ligne est une colonne d'ID

Comme dit précédemment si chaque ligne à un index peu importe sa position. Il existe des méthodes pour trouver instantanément la position d'un index.

Une fois que tu as trouvé sa position (son N° de ligne et sa position relative). Il est aisé de travailler sur cette ligne avec les tableaux structurés.

Dans les forums il est courant de voir les néophytes poser des questions qui tendent à "réinventer lé roue" : Contrairement à ce qui y est présenté gérer une base de donnée correctement n'est pas une partie de plaisir (que ce soit avec ou sans tableau structuré) c'est même un travail d'une extrême minutie si on veux en exploiter le résultat d'une manière professionnelle et sans faille...

Essaie de présenter ta problématique et on te proposera une méthode de travail : T'entêter à chercher dans une mauvaise direction ne t'avancera à rien.

Voici 1 échantillon de base de donnée encore à finaliser mais qui donne déjà un bon aperçu d'une bonne organisation du travail.

Nota : Les dates doivent être entrée sous la forme JJMAAAA

Nota on trouve le même beaucoup plus finalisé ici

A+

Re tout le monde,

"Inutile de préciser le nom de la feuille : ce qui permet de déplacer le tableau sans qu'Excel le perde de vue"

J'ai bien compris cela, aucun souci. Mais vu comme notre ami était parti, suis-je dans le faux en pensant qu'en spécifiant le nom de la feuille, cela aurait résolu plus ou moins le souci ?

Je n'avais pas d'ordi sous les yeux pour tester et j'admets volontiers que je tâtonne encore dans le langage des listobjects.

Edit : Vérification faite sur un ordinateur : "Oui j'avais tort"

Bonjour,

Dans beaucoup de cas l'utilisation de tableaux structurés n'est pas indispensable. On a fonctionné sans pendant 20 ans et de manière très satisfaisante.

Dans la majorité des cas de "petites" bases de données qui se suffisent à elles même et n'ont aucun lien avec des systèmes d'information complexe cela est suffisant. Je pense en particulier aux centaines de milliers d'associations locales qui dans bien des cas se satisfont très bien de cette situation : Le plus souvent elles n'ont pas besoin de tableaux de bord analytiques complexes ni de relation "structurelle" avec une base de donnée fédérale ou nationale. La plupart du temps leur système de données n'est relié (quand il l'est) que pas un numéro de licence ou d'adhérent, et ils fonctionnent en parfaite autonomie.

S'ils offrent de nombreux avantages, mon avis les tableaux structurés s'adressent plutôt à des utilisateurs qui ont une expérience avancé d'Excel ou/et d'autres expériences confirmées de programmation dans d'autres langages car ils nécessitent une capacité d'analyse et d'abstraction assez importante.

Il reste que bien souvent ils ne sont utilisés (à mauvais escient) que par des utilisateurs qui n'y voient que l'attrait de la couleur, la magie des fusions faciles qui permettent de reconstituer "comme sur mon cahier" les même erreurs de conception...

A contrario, l'utilisateur des tableaux traditionnels est obligé de mieux maitriser toutes les contraintes du tableur. Cela s'en ressent jusque dans la qualité des questions posés sur ce forum : On n'y pose plus guère de questions techniques, méthodologique, d'analyse ce qu'on cherche maintenant c'est de l'automatique : le mot clefs aujourd'hui c'est dynamique : il faudrait que à peine commencé ce soit fini...

La programmation VBA (ou autres est un long chemin de persévérance !

A+

Re,

D'ailleurs peut-être suis-je dans le faux, mais en formation je déconseille fortement l'utilisation de ces tableaux aux débutants. Je pense qu'il faut déjà appréhender comment fonctionne Excel d'une façon globale avant de se lancer dedans.

Tant qu'on n'a pas de base de donnée à traiter, de tableaux croisés dynamiques à faire, l'intérêt est moindre.

Et puis l'utilisation de ces tableaux implique que les données soient bien structurées, organisées ... Il y a déjà tellement de boulot à faire là-dessus en amont !

Tant qu'on n'a pas de base de donnée à traiter, de tableaux croisés dynamiques à faire, l'intérêt est moindre.

Bah on arrive encore très bien à traiter des bases de données et des TCD...

Moi je pense que la frontière c'est plutôt les "Power truc" et les relations entre diverses tables...

A+

Effectivement @78Chris tu l'avais écris, mais j'espérais avoir mal compris ;)! Donc je viens d'essayer, les tableaux structurés ne correspondent pas à mon besoin, qui est plutôt de suivre les lignes.

Effectivement @galopin01 mon idée est de reconstituer qqch de semblable à une base de données, donc les lignes doivent être identifiées par un ID unique, qui va être réutilisé dans d'autres feuilles pour faire référence à cette ID et recopier certains champs (colonnes) d'une feuille à l'autre via l'ID.

Par exemple, je souhaite réaliser un dictionnaire de données sous Excel pour un projet SI, dans une feuille "Attributs" je vais définir les attributs de mon modèle de données avec leurs propriétés (type, taille, etc), et dans d'autres feuilles je vais faire référence à ces attributs via leur ID et je souhaite recopier automatiquement leurs propriétés (type, taille, etc) d'une feuille à l'autre.

Dans mon projet actuel je génère bien un ID incrémental afin de suivre les lignes, dans une colonne masquée pour l'utilisateur, mais mon problème est le suivant :

- quand un utilisateur recopie une ligne sans se soucier de l'ID, pour entrer un autre enregistrement inspiré du premier, il recopie aussi l'ID et on a un doublon,

-dans ce cas :

---soit je modifie l'ID de l'enregistrement dupliqué en direct via VBA, mais tout modification VBA fait perdre le retour dans l'historique des modifs et c'est dangereux (on ne peut pas corriger les erreurs faites),

---soit l'utilisateur a à disposition un bouton pour actualiser le fichier à sa guise, le VBA ne s'applique que quand il utilise ce bouton et le reste du temps rien ne se passe, mais dans ce cas dans le doublon d'ID dont je parle plus haut, je ne sais plus reconnaître l'enregistrement d'origine qui doit garder son ID et l'enregsitrement copié qui doit changer d'ID.

Cette perte de la possibilité de retour dans l'historique des modifs est très pénible. Je pourrais programmer dans VBA toute une mécanique de suivi d'historique pour pouvoir revenir en arrière, mais ce serait un chantier bien trop important par rapport à mes ambitions et au temps que je veux y passer.

Voilà toute l'histoire.

@galopin01 je n'ai pas encore eu le temps de regarder le fichier que tu as joint, est-ce qu'il s'agit de simuler une bdd dans un fichier excel? Est-ce qu'il gère cette problématique d'ID unique de ligne vis-à-vis du pb de retour en arrière dans l'historique, dont je parle plus haut?

RE

galopin01 a écrit :

Dans beaucoup de cas l'utilisation de tableaux structurés n'est pas indispensable. On a fonctionné sans pendant 20 ans et de manière très satisfaisante.

sauf quand les utilisateurs, entres autres exemples

• triaient une colonne indépendamment des autres, ceci même après que MS ait ajouté un message de mise en garde...
• oubliaient de créer une plage dynamique comme source TCD ou de liste déroulante et de mettre à jour la définition de la source fournissant des rapports faux

galopin01 a écrit :

S'ils offrent de nombreux avantages, mon avis les tableaux structurés s'adressent plutôt à des utilisateurs qui ont une expérience avancé d'Excel ou/et d'autres expériences confirmées de programmation dans d'autres langages car ils nécessitent une capacité d'analyse et d'abstraction assez importante.

Il reste que bien souvent ils ne sont utilisés (à mauvais escient) que par des utilisateurs qui n'y voient que l'attrait de la couleur, la magie des fusions faciles qui permettent de reconstituer "comme sur mon cahier" les même erreurs de conception...

A contrario, l'utilisateur des tableaux traditionnels est obligé de mieux maitriser toutes les contraintes du tableur.

Je ne partage pas la 1ère assertion. Que l'on fasse un tableau classique ou structuré, il faut réfléchir avant (le travail en amont cité par JoyeuxNoel) et travailler avec rigueur, particulièrement quand on manipule des listes de données.

Je vois pas en quoi un tableau structuré nécessiterait plus de capacité d'analyse et d'abstraction qu'un tableau classique.

Les contraintes et les facilités du tableau structuré aident en cours, si on prend la peine d'y passer un peu de temps, à mettre en évidence la logique d'ensemble d'une liste de données.

En revanche je partage le constat que nombre d'utilisateurs, parfois très experts comme les contrôleurs de gestion, n'y ont vu que la mise en forme et ne l'ont finalement utilisé qu'avec plusieurs années de retard.

Pour en revenir à la question initiale, je pense aussi que la demande de pistage pose question sur l’utilisation du classeur...

78chris a écrit :

Je vois pas en cas un tableau structuré nécessiterait plus de capacité d'analyse et d'abstraction qu'un tableau classique.

Ne serait-ce que la modification des formules (bah oui, parce qu'on met plein de formules dans une BDD)... Un utilisateur non averti sera quand même super vite déstabilisé par les crochets, les @, etc. Pour le reste effectivement on s'y retrouve vite tant qu'on a des bases et qu'on ne franchit pas l'étape de la programmation.

78chris a écrit :

Les contraintes et les facilités du tableau structuré aident en cours, si on prend la peine d'y passer un peu de temps, à mettre en évidence la logique d'ensemble d'une liste de données.

Sur les formations longues, je suis tout à fait d'accord avec toi, il faut en arriver là, c'est important.
Quand tu as une journée, ou 2 maximum, avec un groupe ... Bwarf, je n'ai jamais trouvé le temps de caser ceci au milieu.

RE

JoyeuxNoel a écrit :

Sur les formations longues, je suis tout à fait d'accord avec toi, il faut en arriver là, c'est important.

Quand tu as une journée, ou 2 maximum, avec un groupe ... Bwarf, je n'ai jamais trouvé le temps de caser ceci au milieu.

Oui les boîtes veulent de plus en plus raccourcir les temps de formation. Certains programmes ressemblent à la liste de Prévert : c'est moins poétique mais comme la poésie, cela n'aura pas de véritable incidence sur le boulot quotidien des stagiaires...

Une formation trop rapide, trop dense, sans re situer les fonctionnalités dans un contexte opérationnel, ne sert à rien...

Mon cursus est

1. Initiation sur 2 jours,
2. Données sur 2 jours,
3. Intermédiaire et faux débutants sur 1 jour
4. Perfectionnement sur 2 jours
5. TCD : niveau 1 et niveau 2, chacun sur un jour

On peut faire le 3 avant le 2 selon les besoins, et également faire combiner une partie du 4 et le TCD niveau 1 sur un jour

En interne ou en direct on peut vraiment adapter aux besoins opérationnels et aux niveaux des stagiaires si la DRH fait preuve d'intelligence

Dans les gros organismes, les formations multi entreprises, multi niveaux, sont rarement aussi bénéfiques...

78Chris :

Beaucoup de chose qui semblaient une évidence voire une obligation hier sont devenues complétement obsolète, voire répréhensible aujourd'hui. La pédagogie aussi à eu ses revirements et ses remue méninges.

Je n'espérai pas faire l'unanimité ! Et je ne démontre rien pas plus que toi. C'est juste mon expérience du sujet...

A+

Bonjour à tous,

Comme beaucoup, je pense, j'ai commencé à utiliser Excel sans avoir reçu de formation préalable. On s'aperçoit cependant rapidement comme l'a remarqué Candide Jarczak, que ne pas utiliser au minimum des plages nommées, pose des problèmes de maintenance importants dès lors que l'on commence à développer des applications conséquentes. Dans toutes les formations Excel que j'ai dispensées, c'est évidemment un des points sur lesquels j'ai toujours insisté.

Le tableau structuré apporte des simplifications indéniables au niveau de la mise en forme, des formules et du code. Il ne répond pas forcément à toutes les situations mais certainement à la majorité. Il faut donc apprendre à s'en servir mais effectivement pour un débutant, c'est un peu précoce et il vaut mieux attendre qu'il ait un peu de pratique.

En tout cas, les plages nommées restent un incontournable pour la maintenance ou l'évolution d'une application. J'ai trop vu sur ce forum des demandes de correction d'applications importantes où n'existait aucune plage nommée, évidemment un sacré casse-tête !