Discussion :

[Pierre Fauconnier]

Salut.

Dans la mesure où, au vu des différentes propositions qui pour certaines, ne me semblent pas correspondre à ton besoin de départ, je ne sais plus trop ce que tu cherches à réaliser, d'où tu pars et où tu veux arriver...

Peux-tu repréciser ton propos et éventuellement mettre ton classeur?

[apt]

Re,

Bon, j'aimerais réaliser un gestionnaire d'annuaire téléphonique d'un service technique.

Pour cela, l'utilisateur devra saisir soit un nom de titulaire, soit un numéro de téléphone fixe soit un numéro de téléphone mobile dans un formulaire.

L'utilisateur à le choix de consulter, modifier, d'ajouter ou de supprimer des lignes de l’annuaire.

Voila, en général, l'idée de mon projet.

Merci d'avance.

[Pierre Fauconnier]

Salut.

Je me pose toute de même la question suivante: Pourquoi passer par du VBA pour réaliser cela? A part pour un exercice scolaire, je ne vois pas trop l'utilité, alors qu'Excel a tout ce qu'il faut en magasin pour réaliser cela par filtrage sur un simple tableau structuré et peut modifier ce qu'il souhaite directement dans les cellules du tableau. Il est possible de placer des validations à la saisie pour contrôler ce qui est entré. Ca prend à tout casser 10 minutes de mettre cela en place en Excel.

De plus, tu parles de listbox, mais dans le fichier que tu joins, tu montres une feuille Excel en guise de formulaire
Pourquoi veux-tu passer par du vba?

[apt]

Bonsoir Pierre,

Je n'ai pas bien une vue claire de ce que tu avances, mais, j'ai pensé qu'en VBA, en peut bien gérer une bdd, avec toutes les opérations nécessaires à cela.

Donc, en VBA j'ai bien avancé, après l'aide que j'ai eu, mais si tu veux, j'aimerais bien voir l'idée que tu avances

Merci d'avance.

[Pierre Fauconnier]

Salut.

Quelques principes de base:

• On essaie d'utiliser le meilleur outil, le plus adapté, pour un travail donné (quitte à apprendre à s'en servir);
• Excel n'est pas un gestionnaire de base de données, au départ;
• On essaie de ne pas réinventer la roue de ce qui existe déjà;
• Si on doit coder, on s'appuie au maximum sur l'outil que l'on a choisi (Excel, dans ton cas).

Cela dit, lorsque tu crées un tableau structuré (ce que tu as fait, comme je l'ai vu dans le fichier que tu as donné), tu as normalement les outils de filtre qui se placent sur la ligne d'entête.

A partir de là, tu peux filtrer sur les colonnes de ton tableau, relâcher un ou plusieurs filtres d'un coup, rechercher des correspondances approximatives avec les jokers * et ?. Tu peux supprimer une ligne, en ajouter, en insérer. Tout cela peut s'effectuer sans aucune ligne de code. Si tu places de la validation sur tes données, toujours sans code, tu peux imposer la saisie d'une date dans une colonne de date, une valeur numérique entière, un élément présent dans une liste, ... Cette validation s'étendra sur les nouvelles lignes de ta table. Tu peux y placer de la mise en forme conditionnelle qui, elle aussi, s'étendra aux nouvelles lignes.

Avant donc de développer une "application" Excel avec des userforms et du code, il est probablement intéressant de définir ce que tu dois obtenir in fine, à qui est destiné ton fichier, en te disant qu'il est probablement moins coûteux d'apprendre à quelqu'un à manipuler les filtres automatiques qu'à tenter de les remplacer par du code. Pense que si ton userform doit gérer des dates, par exemple, tu ajoutes une certaine complexité à ton appli => saisis 01/02/2020 dans un textbox de userform puis regarde ce qui atterrit dans une cellule avec un code du genre range("a1").value = textbox1.value... ^^

Cela dit, si ta passion est de coder et que tu en fais un jeu, ok, passe par un userform et amuse-toi, c'est très bien. Mais très basiquement, saisir des données dans un tableau structuré, supprimer des lignes, filtrer pour rechercher de l'info, ça se met en place en 10 minutes chrono avec les outils natifs d'Excel.


My two cents

[apt]

Bonjour Pierre,

Merci pour tes précieux conseils.

Primo, cette application est destinée aux agents d'un service, ou tout le monde ne s'est pas utilisé l'outil Excel

Donc, leur faciliter la tache est le principal but de cette application.

Secundo, j'en ai l'habitude, est je ne sais pas si c'est un défaut ou pas, là ou je vois des taches répétitives, de les coder tout simplement

Tertio, Excel, je sais, n'est pas l'outil idéal pour gérer des grosses bases de données, Access est fait pour cela (Pourtant je m'en suis pas encore servi) , mais pour gérer quelques centaines de lignes comme c’est mon cas, on pourra avoir un bonne résultat.

Encore merci pour conseils.

[OrDonc]

Bonsoir …

Pour jouer un peu, un autre exemple …
Dans un commentaire tu trouveras quelques pistes à suivre (ou pas).

[Pierre Fauconnier]

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.

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

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.

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

[Pierre Fauconnier]

[...]
Primo, cette application est destinée aux agents d'un service, ou tout le monde ne s'est pas utilisé l'outil Excel

Donc, leur faciliter la tache est le principal but de cette application.[...]

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

[apt]

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