Bonsoir …
Pour jouer un peu, un autre exemple …
Dans un commentaire tu trouveras quelques pistes à suivre (ou pas).
Bonsoir …
Pour jouer un peu, un autre exemple …
Dans un commentaire tu trouveras quelques pistes à suivre (ou pas).
Il serait moins coûteux de leur apprendre les bases d'Excel (filtrer avec les outils natifs n'a quand même rien de compliqué, ajouter une nouvelle ligne de données, surtout avec de la validation, est normalement à la portée du premier venu) que de développer du code (surtout si on n'est pas programmeur) qui va inévitablement rendre le classeur plus fragile et imposer, de toute manière, une formation même légère sur l'outil développé... De plus, dans les codes qui t'ont été proposés, il n'y a aucune gestion d'erreurs, et donc si ça plante, ton utilisateur "qui ne sait pas utiliser Excel" va se retrouver dans du VBA avec une belle ligne jaune, des événements qui ne fonctionneront plus parce la gestion des événements a été désactivée sans aucune précaution, etc... C'est sûr que ça va les aider ^^ Si on a des utilisateurs qui sont nuls à ce point, on leur propose un truc bétonné dans une application fermée et pas un bricolage mal foutu en Excel...
My two cents...
"Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
---------------
Mes billets de blog sur DVP
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...
---------------
Bonsoir OrDonc, Pierre,
Merci OrDonc pour ton dernier exemple.
Pour Pierre, la gestion d'erreurs, c'est une partie non négligeable dans un code. Merci de nous l'avoir rappeler son importance![]()
Franchement...
Je me pose à nouveau la question de l'utilité de la ligne jaune avec les listes déroulantes qui masquent les outils natifs de filtre Excel. En plus, si je tente de saisir une valeur de la liste sans l'ouvrir, j'ai des beaux caractères ésotériques... Effectivement, pour "jouer" un peu ^^
J'ai vraiment des difficultés à comprendre à quoi sert de réinventer, en moins bien, en plus fragile et en moins fonctionnel, ce qui existe en natif dans Excel, pour finalement, par code, replacer le filtre automatique.
Je rappelle également qu'un Application.EnableEvents = 0 (outre le fait que c'est plus compréhensible d'écrire False que 0, même si "ça fait mieux" d'écrire 0) doit être utilisé avec une gestion d'erreurs, car en cas d'erreur et de sortie brusque du code, les événements ne seront plus gérés. Et ce n'est pas la procédure Sub evO(): Application.EnableEvents = 1: End Sub qui sert à grand chose comme son commentaire 'pour rétablir les évènement en cas d'erreur le laisse supposer, puisqu'elle n'est jamais appelée par le code. et on ne voit pas bien quand elle serait appelée puisqu'il n'y a pas de gestion d'erreurs. De plus, perso, je ne suis pas fan de l'écriture, ça coûte quoi de respecter les blocs et l'indentation? Dans du code à usage personnel, on fait ce qu'on veut, mais lorsque l'on partage sur des forums, il me semble normal d'adopter un style plus classique qui ne perd pas les personnes que l'on est censé aider (avis personnel).
Il serait préférable d'écrire le code suivant, qui, en plus, éviterait l'Exit Sub.
Je rappelle également que normalement, le code événementiel ne doit rien faire d'autre que d'appeler du code applicatif. Ca clarifie le code, ça permet de comprendre quelle procédure fait quoi, ça facilite les tests et ça rend l'évolution du code plus aisée.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13 Private Sub Worksheet_SelectionChange(ByVal R As Range) On Error GoTo EndHandler If R.CountLarge <= 1 Then Application.ScreenUpdating = False Application.EnableEvents = False .... ... End If EndHandler: Application.EnableEvents = True End Sub
J'ai déjà dit dans une autre discussion ce que je pensais de l'écriture à crochets [Tb].Rows(0) qui prive de la saisie semi-automatique, qui amène de la confusion dans le code car on ne sait pas avec quoi on travaille et qui impose du Late Binding à tout coup (Voir mon billet à ce sujet). C'est une source non négligeable d'erreurs de code et ça en ralentit l'exécution. A part "faire initié" et à nouveau perturber la personne que l'on est censé aider, je n'ai jamais compris à quoi ça servait ^^
PS: Je précise pour les esprits chagrins que je ne fais que donner mon avis![]()
"Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
---------------
Mes billets de blog sur DVP
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...
---------------
Partager