Discussion :

[fergut]

Bonsoir

J'ai appliqué tes modifications sur la fonction Ajout et ça marche merci

Ajout j'ai réalisé d'après un tuto de Learnacces je l'es ai écrites.

Quand aux autres fonctions j'ai transposé des fonctions d'Alex, alors ces choix me dépasse et je ne voudrais pas qu'elles viennent en contradiction avec celles d'Alex.
Et je vous laisse débattre ensemble

Merci pour ta participation.

[Alex020181]

Bonjour,

Je l'ai dit dès le début dans l'une de mes premières réponses; "c'est une des méthodes. Chaque développeur a ses habitudes" et je comprends tout à fait que des tableaux structurés peuvent être préférables avec le code qui va avec.

Le fichier reçu de Fergut a déjà du code, les colonnes des feuilles, certaines feuilles sans tableau et d'autres avec, les formulaires enregistrés. J'ai complété quelques petites parties. Le restant c'est lui seul avec ses recherches Internet et je préfère qu'il ait un code qu'il a créé et qu'il comprenne plutôt que de lui dire de tout recommencer et de lui demander d'utiliser du code tableau.

Je suis d'accord que le code qui était présent est facilement corrigible car pas optimisé (activate, activecell, offset, ...) mais Fergut arrivait quand même a ce qu'il voulait donc même si c'est pas le top et même si ce n'est pas du code utilisant les fonctionnalités tableaux je ne vais pas lui dire de tout recommencer pour utiliser les fonctionnalités tableaux.

De mon côté je n'ai pas non plus utilisé les fonctionnalités tableaux dans le code ajouté, et même si vous pour vous j'ai utilisé des "techniques obsolètes" car j'ai préféré pointer directement des références cellules et pas des noms de colonnes de tableaux. Je sais bien que cette méthode n'est pas l'extase des grands développeurs mais elle permet au moins de savoir cibler précisément une cellule ou une plage pour travailler dessus. Ce qui est plus "comestible" pour un débutant pour comprendre que de directement taper dans les évolutions de code optimisées de type tableau. Je sais bien aussi que j'ai mis un code avec une boucle qui parcoure les cellules de haut en bas pour rechercher le codeadherent alors que j'aurai pu utiliser match (ou encore les tableaux). Cela permet à Firgus de commencer à voir les boucles. Je sais bien que...

Je sais aussi que si l'utilisateur renomme une feuille le code plantera ..... tout comme il plantera en utilisant la méthode magique des tableaux si l'utilisateur change ou supprime un nom donné au tableau ou tout comme il plantera si l'utilisateur supprime une colonne du tableau. Donc quoi qu'il en soit avec ou sans tableau il y a risque de plantage suite manipulation utilisateur. Tout comme un renommage de feuille il faudra également modifier le code en cas de modification de noms ou de suppression de colonne. Je ne suis pas certain que l'utilisation de tableau "sécurisent le code". Modifier le nom d'un tableau ou d'une de ces colonnes et c'est pareil; il y aura plantage.

Je sais aussi que sheets représente une feuille de manière générale et que worksheet représente une feuille contenant des données à la différence d'une feuille contenant un graphique. Là pour le coup oui il aurait été plus propre d'utiliser worksheet. Mais cela permet de ne pas m'obliger à faire moi-même cette différenciation. Avec sheets Excel atteindra la feuille en question que ce soit une feuille de données ou non. Je n'ai par la suite pas forcément accès à ctrl+espace.

Je sais aussi que End(xlDown) ou Up n'est pas l'extase; il faut par exemple commencer par défiltrer la feuille et démasquer les lignes éventuellement masquer sinon seule sont prises en considération les lignes (ou colonnes) affichées. Il ne doit pas non plus y avoir de cellules vides.

Bref, je sais que chaque proposition de code aura ses faiblesses... tout comme l'utilisation de tableaux.

Par contre je ne suis pas d'accord quand vous dites "la première chose à faire est de remettre les données en tableau". On a tout à fait le droit de ne pas utiliser les tableaux. On peut tout à fait décider de ne pas utiliser l'utilisation de cette fonctionnalité qui oblige également à utiliser les plages nommées. Si je ne veux pas ou même ne peux pas par-ce que la feuille est protégée et que je ne peux pas la déprotéger. Je reste libre de ne pas transformer les plages en tableaux. C'est une préférence (ou une incapacité dans le cas d'une feuille protégée). Quitte à utiliser du code qui, pour vous, est obsolète.

Le code utilisant les fonctionnalités tableau ne fonctionnera que si l'utilisateur a créé des tableaux et s'il n'en a pas modifié les noms, ni les noms des plages nommées. Le code sans VBA tableau fonctionnera que l'utilisateur aie ou non créé des tableaux même si cela oblige à d'autres contraintes (renommage feuille par exemple).
Je ne dis pas que la méthode avec plages de cellules est meilleure et sans inconvénients mais je dis que les tableaux ne sont pas non plus une méthode magique absente de contraintes qui rend toutes autres méthodes "obsolète". Il y a des avantages et inconvénients dans les 2 cas. Plus ou moins peut-être mais "la première chose à faire est de remettre les données en tableau" non.

Concernant PQ je ne sais pas. Je n'utilise pas. Je connais le principe et j'ai déjà vu mais sans plus.

Ce que je sais aussi c'est que j'ai déjà eu un fichier de gestion de budget avec pleins d'onglets, de PQ, de tableaux de plusieurs dizaines de Mo (20 de mémoire) qui mettait un temps fou à s'ouvrir et à mettre à jour les requêtes PQ. La responsable budget à été bien contente de récupérer un fichier sans tableaux ni PQ de 1Mo avec formules qui s'ouvrait rapidement et dont les formules que j'avais implantées répondaient immédiatement.

Fergut, dans le cas présent, ou n'importe quel utilisateur utilisera du code qu'il comprend et évoluera ses compétences par la suite. Quitte à, au début et quelle que soit la durée de ce "début", commencer par du code que vous jugez "obsolète".
Maintenant je comprends aussi l'agacement que cela peut engendrer quand ensuite une personne plus expérimentée reprend le projet. Paris ne s'est pas fait en un jour même si on aurait pu mieux faire et plus vite dès le début.
Je pense qu'on doit apporter de l'aide en donnant du code compréhensible facilement par le demandeur selon ce qu'on pense de son niveau initial et pas forcément directement lui fournir un code plus poussé.

[Pierre Fauconnier]

En 25 ans de métier, j'ai évidemment déjà entendu toutes tes objections. Je les balaie toutes car aucune ne tient la route.

On est pas responsable de la forme des données que l'on reçoit, mais on est responsable de ce que l'on en fait. Si je récupère des données d'une feuille protégée, mal formées, mal organisés, etc, je crée un peu de code pour copier les données sur une feuille non protégée en les remettant d'équerre puis je travaille avec les outils d'Excel qui, sur les versions actuelles, sont tous prévus pour les tableaux structurés comme "zone de stockage" de l'info. Souvent, ça permet de limiter le VBA à cette remise d'aplomb, alors que travailler sur des données mal conçues amène à créer des formules tordues bourrées d'exception et qu'il faut souvent créer du code VBA pour réaliser ce qu'Excel permet nativement sur base de données bien construites.

Tu connais un fichier lourd et qui plantait, était lourd à l'ouverture, etc? Wouah. As-tu analysé les causes de ces lenteurs et lourdeurs? As-tu pu isolé ce qui expliquait ces problèmes? Moi aussi tu sais, j'en connais et j'en ai vu passé, mais ils étaient souvent, voire toujours, mal conçus. En les remettant d'équerre, ils perdaient en poids et gagnaient en vitesse. J'ai une fois dit à un client/ami qui se plaignait de la lenteur de son fichier à l'ouverture que vu le temps qu'il passait à la machine à café, il n'avait qu'à ouvrir son fichier avant d'aller chercher son kawa. Je ne l'ai plus jamais entendu parler de lenteur sur un fichier Excel, depuis.

On accuse souvent Power Query de lenteur, avant de se rendre compte que en Power Query, on a aussi plusieurs chemins dont certains sont plus lents que d'autres, que lorsque les données en amont sont sur un serveur, la lenteur peut venir de la connexion bien plus que de Power Query, etc. Je termine un travail actuellement pour un tableau de bord qui va récupérer 7 millions de lignes dans une compta assemblées en SQL avec plein de jointures dans tous les sens. C'était très lent et attribué à Power Query. On a sauvegardé l'historique jusqu'à fin 2019 dans une table à plat en SQL, qu'on merge avec Power Query sur la compta depuis 2020 et c'est devenu instantané. Mais au départ, on a incriminé Power Query. Les problèmes de lenteur, ç'est presque toujours un problème de conception et d'étude du cas. On y revient toujours, à la conception. Qui pourrait soutenir qu'on va créer un building sur des fondations que l'on sait mauvaises au prétexte que comme elles ont déjà été faites, on ne va pas les détruire pour recommencer du plus solide? Pourquoi soutenir pour un développement ce que tu ne soutiendrais pas s'il s'agissait des fondations de ta maison? Ca n'a pas de sens.

Renommer un tableau ou une colonne fera planter le code? Oui, c'est vrai, sauf que l'on peut tester l'existence de la colonne ou du tableau avant et dérouter le code en cas de problème. Ca a toujours été le cas en informatique. Tu développes du vba pour Access. Te sais donc qu'une requête select NomDuChamp1, NomDuChamp2... from MaTable utilise les noms des champs plutôt que leur index. Pourquoi? Parce que l'on renomme rarement une table et ses colonnes, et que cela permet de ne pas se tracasser de l'ordre des colonnes. Et tu sais aussi que si tu renommes la table ou ses champs, ta requête SQL plantera. Utilises-tu la place des champs plutôt que leur nom dans tes requêtes? Non. Pourquoi le ferais-tu en Excel? Tu renommes ta table et tes champs tous les matins? Non, pourquoi le ferais-tu en Excel. C'est pareil en Excel. Si dès le départ on nomme correctement les tableaux et les colonnes, on ne va pas s'amuser chaque matin à les renommer. On en ajoutera, parfois on en insèrera, on en supprimera très rarement et on ne les renommera normalement jamais.

Pour moi, il ne s'agit pas ici "d'habitudes de programmeur", il s'agit de "bonnes techniques" à mettre en place avec les outils actuels. Personne, je suppose, ne soutiendrait qu'il est bien de "programmer" avec les macros XL4 qui pourtant étaient la norme il y a très longtemps. Soutenir qu'on peut développer avec les macros XL4 au prétexte d'une "habitude de développeur" ne tiendrait pas du tout la route. Pour moi, soutenir que "par habitude" de programmeur, on va programmer sur des plages classiques plutôt que sur des tableaux structurés, ça ne tient pas la route et c'est indéfendable. Que certains cas très spécifiques et très rares justifient de se passer des tableaux structurés au profit des plages classiques (en VBA comme en Excel) n'en fait pas une norme de programmation. Dans le cas vu ici, aucun argument technique ne peut justifier que l'on n'utilise pas les tableaux structurés qui, en Excel comme en VBA, amènent de la fiabilité, de la stabilité au classeur tout en facilitant la maintenance et l'évolution du classeur ou de la solution mise en place. Quel professionnel pourra justifier de l'utilisation de pratiques obsolètes au titre qu'il a l'habitude de programmer ainsi?

Pour ce qui concerne tes "arguments" pédagogiques et didactiques, ne connaissant pas ton expérience de formateur ni les formations que tu as en pédagogie et en didactique, je vais en rester là, ne sachant pas sur quelles "vérités" tu t'appuies pour énoncer tes propos. Mais ta position sur le sujet étant à l'opposé de la mienne, nos vues, sur ce point comme sur les autres, sont difficilement conciliables

[Patrice740]

Bonjour Pierre,

... Que certains cas très spécifiques et très rares justifient de se passer des tableaux structurés ...

Je suis entierement d'accord sur le fait qu'il faut exploiter au maximum les fonctionnalités natives du tableur.
Et aussi sur le fait que pédagogiquement, il ne faut jamais enseigner de mauvaises pratiques.

Mais il y a un cas, spécifique je le concède, mais ni très rare, ni très spécifique, où on doit (malheureusement) se passer des TS :
celui où le fichier doit fonctionner aussi bien avec Excel qu'avec Libre Office.
Même certaines administrations ont choisi Libre Office et doivent communiquer avec des utilisateurs de MSO.

[Pierre Fauconnier]

@Patrice,

Le VBA ne passera pas non plus, je doute que les TCD, graphiques, listes de validation, etc, etc, passent bien la rampe sans problèmes. Donc pour moi, un fichier utilisé à la fois sur Excel et d'autres solutions se résumera à un collecteur de données brut de toutes fioritures, une simple feuille de saisie, et en s'assurant, si formules il y a, qu'elles aient la même syntaxe des deux côtés.

Et donc, pour l'exploitation des données, on aura un autre fichier Excel qui sera lié à ce "conteneur de données", idéalement par Power Query qui ramènera les données dans le classeur de traitement sous forme... d'un tableau structuré. Et même si on y ramène les données par VBA, ce sera bien entendu pour les injecter dans un tableau structuré.

[Pierre Fauconnier]

[...]
Par contre je ne suis pas d'accord quand vous dites "la première chose à faire est de remettre les données en tableau". On a tout à fait le droit de ne pas utiliser les tableaux. On peut tout à fait décider de ne pas utiliser l'utilisation de cette fonctionnalité qui oblige également à utiliser les plages nommées. Si je ne veux pas ou même ne peux pas par-ce que la feuille est protégée et que je ne peux pas la déprotéger. Je reste libre de ne pas transformer les plages en tableaux. C'est une préférence (ou une incapacité dans le cas d'une feuille protégée). Quitte à utiliser du code qui, pour vous, est obsolète.[...]

Mais oui tu as le droit de ne pas utiliser les tableaux. Ai-je obligé à utiliser des tableaux structurés sous peine de mort? On n'a plus que ce mot-là à la bouche maintenant "avoir le droit". Tu as le droit de préférer des mauvaises techniques, j'ai le droit de dire qu'elles sont mauvaises (à mon estime), d'expliquer pourquoi elles le sont et d'en conseiller des meilleures à la place. "Avoir le droit"... ^^.

Utilise des plages classiques si tu veux, personne ne te l'interdit. On a le droit d'utiliser les pratiques obsolètes si l'on veut. Je dis simplement que travailler avec les outils actuels et donc les tableaux structurés est une meilleure pratique dans la toute grande majorité des cas, et que "on a le droit" (le devoir, en tant que professionnel?) de se former aux nouvelles techniques. Tu as même le droit de dire qu'il vaut mieux utiliser des plages classiques plutôt que les tableaux structurés, mais viens défendre ta cause avec des arguments en béton dans ce cas, que je démolirai un par un (avoir connu UN classeur qui était lourd ou avoir une vague idée de ce qu'est la pédagogie ne sont pas des arguments en béton). J'ai pour ma part bien précisé que "certains cas très spécifiques et très rares justifient de se passer des tableaux structurés ..." et tu viens me sortir UN fichier très lourd (probablement mal conçu) que tu as pu alléger avec de belles formules sans que l'on ait pu analyser exactement à quoi étaient dus les problèmes de lenteur, et Patrice vient avec un cas qui de toutes façons plantera pour d'autres raisons et fera que, tel quel, on ne pourra pas utiliser toute la puissance des outils Excel. Ca ne tient pas la route, vos exemples. Je viens de voir passer sur le forum un beau tableau structuré avec un SOMME.SI.ENS qui reprenait toute la colonne B:B au lieu d'utiliser la référence structurée, alors je peux aussi venir avec des cas, si on veut jouer.


Pour les pseudo-arguments pédagogiques, j'ai plus de mal, par contre, car je pense que "on n'a pas le droit" d'enseigner des techniques obsolètes ou mauvaises (pour moi une technique obsolète est mauvaise) sous prétexte de pédagogie (sauf à des fins de comparaison, pour montrer en quoi elles sont obsolètes ou mauvaises). Je veux bien discuter pédagogie et didactique de l'informatique avec des profs et des formateurs (des vrais hein, qui ont des centaines d'heures de vol, pas des gens qui ont une fois expliqué comment "on fait une somme" en Excel ou des profs de math qu'on a parachuté "prof d'Excel"), mais je n'ai pas envie de perdre mon temps sur ce terrain avec des gens qui n'auront pas apporté la preuve de leur maîtrise en la matière.

[fergut]

Bonjour
J’ai complété les codes du bouton « Reprendre la modif dans feuille » ça fonctionne merci
La fonction MAJ est la plus fréquente (95%), Ce que je souhaiterais, si possible :
Utiliser la zone verte du formulaire.
Mettre à jour : Renter un code adhèrent existant à mettre à jour.
Visualiser : Efface les données du formulaire existant, affiche tous les champs correspondant au code demandé, dans le formulaire,
possibilité de modifier tous les champs sauf ceux servant au calcul du code (c’est déjà le cas)
Peut être un bouton efface l'enregistrement sur la BDD en cours
MAJ valide la mise à jour sur BDD en cours.

Dans l'attente de votre réponse
Merci encore

https://fromsmash.com/LnNaIu3AkB-ct

[Alex020181]

Bonjour,

Le bouton "visualiser" rappelle sur le formulaire les données de ta feuille "BDD en cours" selon le code adhérent "TextCodeMaj". Tu n'as pas besoin de réinitialiser les champs puisque leur valeur sera directement remplacée.

Je n'ai pas compris ce que tu veux avec ton bouton "MAJ".
Tu veux modifier la feuille "BDD en cours" avec les valeurs du formulaire ? Tu as déjà le bouton "Reprendre la modif dans feuille" qui te fait ça.

Attention avec le bouton "supprimer". La ligne est supprimée mais quand tu gèreras les parcelles il faudra réattribuer ses parcelles avant de supprimer l'adhérent.

[fergut]

Bonjour
Merci pour ta réponse
En début d'année j'envoie à l'adhérent sa feuille de renouvellement qu'il peut modifier ou non, je dois donc visualiser toutes ses données pour éventuellement les modifier ( sauf nom, prénom INSEE et doublons "dans ce cas je dois supprimer et recréer")
On pourrais peut être aussi avoir une fonction mise à jour du code!, c'est souvent le cas notamment dans les successions, noms, prénoms villes peuvent changer mais la propriété reste la même!.
Je devrais aussi modifier l'année pour l'actualiser.
Doublons: Dans le calcul du code adhérent je crois que sur un champ calculé on ne peut pas vérifier les doublons, c'est bien le cas ? si oui avec la fonction ajout on peut ajouter une macro pour vérifier.
La fonction supprimer il est possible de demander confirmation.
Bonne journée et merci

Complément

J'ai essayé de formater le champ txtCot_Soutien du frmSaisie et ça ne passe pas !

Code :

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

1
2
3
4
5
6
7
8
9
'Formats numériques
 
 Private Sub Userform_initialise()
 
    Dim Cot_Soutien As Double
    Cot_Soutien = 1234
    txtnombre.Value = Format(Cot_Soutien, "0.00")
 
  End Sub

Merci de bien vouloir me renseigner.

[Alex020181]

Bonjour,

Le code est mal placé.
Chaque code est relié à un événement déclencheur. Dans le cas présent tu l'a mis sur l'événement d'initialisation. Il ne se déclenchera qu'au moment de l'initialisation de ton formulaire ...

Je regarderai plus en détail

[Alex020181]

Pour comprendre où positionner le code en fonction des événements que tu souhaites (le code placé sous chaque événement s'exécute si l'événement est activé)
https://excel-malin.com/a-la-une/lis...-excel-events/

Pour les types de données
https://docs.microsoft.com/fr-fr/off...a-type-summary

Pour le format d'affichage des nombres

champ_destination = Format(valeur_a_afficher, "#,##0.00") --> pour séparateur de milliers à 2 décimales
champ_destination = Format(valeur_a_afficher, "#,##0") --> pour séparateur de milliers à 0 décimale

Je t'ai ajouté l'affichage avec séparateur de milliers à 2 décimales dans les cotisations (regarde la fonction) et la demande de confirmation de suppression.

[fergut]

Bonjour
Merci pour l'envoi
Est il possible de traiter la zone verte 95 % de l’activité 'vraiment de l'inattention
Avec sa cotisation l’adhérent envoie sa fiche, on la visualise, la modifie ou la complète si nécessaire, lui attribue une année, et la valide ou encore la supprime de la BDD ?'vraiment de l'inattention
On doit donc visualiser tous les champs.
Pour les formats j’ai complété écart je n’y suis pas arrivé c’est peut être du fait qu’il faut le calculer txtEcart=txtRegle-txtTot_cot !, aussi Reglement, téléphones, mails et surface foret (mille hectares = 1 000 00 00)
Merci de bien vouloir me renseigner.

[fergut]

Salut

Vraiment je suis gêné par ce manque d'attention et je te prie de bien vouloir m'en excuser
J'ai complété les codes comme tu l'as demandé
Il reste seulement les pbl de format.
Je joins également les derniers codes pour l'adresse de l'adhérent et aussi pour les parcelles
Tu trouveras les fonctions Excel qui fonctionnent sur la feuilles adhérent.
Si possible je souhaiterais avoir la même procédure " je rentre le code postal je choisis la ville le département et l'INSEE sont renseignés.
C'est d'ailleurs une procédure que l'on retrouve souvent.
En fin d'ajout est ce qu'il est possible de faire un contrôle des doublons entre le dernier code généré et les codes existants dans la bdd en cours, dans ce cas on rentre manuellement premier chiffre ex:1 dans " doublon " et le dernier code est différencié.
Merci pour tout le travail accomplis il méritait une meilleure attention.
1000 excuses.

[fergut]

Dernière modification.
J'ai déplacé le bouton de mise à jour des données.
Avec la fonction visualiser est ce qu'il est possible de faire défilé la BDD ?
Est il possible d'incrémenter Id ?
Dans les formats j'ai oublié date !
Ajoute: est il possible d'insérer une ligne vide après avoir ajouté les nouvelles données pour préserver la totalisation des colonnes.
Code adhérent MAJ si possible avec liste déroulante de la BDD.

Merci