VBA procédure trop grande
Bonjour,
Je fais un userform pour enregistré des données cependant j'ai beaucoup de lignes et du coup ma procédure est trop grande.
Connaissez vous une astuce ?
Merci
Amandine
Bonjour,
Qui te dit qu'elle est trop grande ? Et laquelle ?
A ce que j'ai vu (survol panaramique de quelques secondes)
- De longues énumérations dans des procédures, qui devraient être codées au moyen de boucles. Il faut toujours faire le maximum pour utiliser des boucles, et s'arranger pour pouvoir en utiliser quasiment partout, cela allège très notablement le code.
- Là je n'ai pas eu le temps d'apercevoir d'application possible, mais on allège également en modularisant : c'est à dire, procédure élémentaire faisant une chose et une seule qui peut être appelée par diverses procédures ayant la chose à accomplir, en lui communiquant les paramètres adéquats pour que cela se fasse aux conditions voulues.
Un exemple qu'on rencontre souvent : 2 procédures d'affectations d'éléments à une base de données, selon qu'on ajoute ou modifie un enregistrement. Dans un tel cas c'est trivial, car la procédure est rigoureusement la même ! Seule la ligne change. Il suffit donc de la transmettre en paramètre à une seule procédure commune...
Mais on peut aller plus loin et définir une procédure commune d'affectation ou outre la ligne, la feuille, le nombre de colonne servies seraient des paramètres variables, et également pour la source des affectations qu'on peut faire varier. Cela demande un travail en amont, mais à l'arrivée on aura fortement réduit le code...
- Autre constat rapide : beaucoup de Userforms, plusieurs semblables, et complexes... Et il me semble que leur construction les personnalise au point qu'ils en viendraient à remplacer la base de données !
Cela ne me semble pas être la meileure utilisation de Userforms, que je conçois plutôt génériquement et le plus simples possibles : on a à saisir des quantités de données différentes sous des formes semblables, avec des éléments à prélever pareillement et des éléments à affecter pareillement... cela justifie un (1) Userform, modulable pour répondre à l'ensemble des données traitées successivement.
- Détail : déjà 2 Modules standard. Un seul est justifié, le volume de code justifie rarement l'accroissement du nombre de modules ! Ce qui le justifie, ce sont par exemple des fonctionnalités spécifiques amenant à mettre des variables hors de portée des procédures du module principal, ou des blocs de fonctionnalités liées que l'on veut pouvoir exporter séparément...
La multiplication des composants n'a aucun intérêt ; chaque fois qu'on tend à en ajouter un, il convient d'analyser soigneusement les raisons qui justifient cet ajout et leur caractère impérieux.
Rapide. Mais je n'aurais pas le temps de tout lire... Le problème est que mes conseils ou d'autres que l'on pourra te donner, auraient leur plein effet au niveau de la conception d'un projet. Au milieu du gué, il est rare que l'on puisse faire plus que du ravaudage.
Mais ce n'est pas inutile de le dire : moi-même je me limite souvent à du rafistolage pour parer au plus pressé, mais vient toujours un moment où une révision d'ensemble s'impose, et là on peut alors balayer pour rebâtir autrement, en tenant compte des problèmes et analyses antérieurs, et rebâtir de façon plus modulaire (c'est souvent sur cet aspect que les conceptions initiales pèchent) qui facilitera des modifications par changements de telle ou telle "pièce" de la "machine" sans affecter ses autres fonctionnalités...
Cordialement.
Merci pour votre réponse,
J'ai fais des userform qui se ressemble car tout ne rentré pas dans un seul userform (alors que cela était mon but).
Je ne sais pas comment faire de boucle avec des textbox.
Merci
Ce que j'ai dit :
- Les Userforms qui sont conçus de façon semblables n'ont pas lieu d'être ; on n'en ouvre qu'un à la fois et lorsqu'on l'ouvre on peut changer avant affichage les mentions des étiquettes et ce qu'on y met.
Et le même peut servir à plusieurs usages...
- Afficher quasiment le contenu d'une feuille de données dans un Userform, c'est une hérésie ! Si je veux voir l'ensemble des données, je vais sur la feuille les voir.
- Un Userform ça sert principalement à saisir de nouvelles données et à afficher des données existantes en vue de les modifier éventuellement, par lots apparentés, selon la façon dont les données sont organisées. C'est normalement un même Userform qui remplit ces fonctions, elles tout à fait similaires. Le reste (quoi ?)... peut de toutes façons se faire ailleurs. [Je passe sur quelques utilisations marginales qui peuvent s'avérer intéressantes ou nécessaires mais qui demeurent anecdotiques ; ce sont dans ces cas des Userforms plutôt légers.]
- Le code indispensable dans un module de Userform est celui qui sert à gérer son fonctionnement interne. Ce qui relève des entrées et sorties peut, en tout ou partie être dans un module standard.
J'ai précisé un peu plus car tu ne semblais pas avoir compris...
Pour ce qui est de faire des boucles avec des contrôles, s'arrange pour qu'ils aient un nom générique suivi d'un numéro d'ordre permettant de les défiler en boucler (ils sont nommés ainsi par défaut, mais il faut parfois arranger un peu, et il est conseillé de renommer les contrôles pour mieux s'y retrouver et créer la meilleure situation à l'exécution, [et à mon avis mettre des noms plus courts !
Controls("NomGénérique" & i).Value
On s'arrange par exemple pour que les TextBox dont les valeurs sont à affecter sur une ligne de feuille, soient dans le même ordre que les colonnes d'affectation, et au lieu d'une énumération insipide, on a une boucle qui occupe 3 lignes.
Cordialement.
Merci pour vos conseils.
Avez- vous des exemples ou un cour pour m'aider ?
Je vais essayer de tout recommencer, mais j'apprends sur le tas et la ce que vous me dite, je le comprend mais j'ai aucune idée de comment le réaliser.
Merci beaucoup,
Bonjour,
Excuses pour délais de réponse...
Comme sources et références, il y a d'abord les sites spécialisés Excel-VBA dont les deux principaux à ma connaissance : Excel-Pratique (celui-ci) et Excel Download. Tu pourras en trouver d'autres, j'ai perdu un peu le fil des mouvements en la matière, certains ont disparu, d'autres sont peut-être apparus... Je pense que tu peux te servir du site sur lequel on est comme référence pour étalonner la qualité de ce que tu peux trouver ailleurs. En particulier, tu trouveras ici des cours pour l'apprentissage structuré d'Excel et VBA (nécessaire pour ne pas s'en tenir à des recettes de cuisine ponctuelle qui ne peuvent jamais être pleinement et correctement utilisées si on ne dispose pas des bases).
Autre site qu'il convient de citer : boisgontierjacques.free.fr. Tout le monde y trouvera beaucoup de choses... C'est une véritable mine d'or ! Mais je dirais que pour utiliser son contenu de façon profitable il vaut mieux ne plus être tout à fait débutant, car il est très dense et compact et réclame un effort de compréhension assez soutenu.
(Je m'explique, sur une solution donnée pour un cas de figure précis, tu vas trouver sur place des explications non données ailleurs et qui concerne ce cas de figure, mais pas les explications déjà données ailleurs, ce qui explique que des débutants tombant sur la solution au problème qu'ils veulent résoudre, n'arrivent pas à la mettre en place, car n'ayant pas assimilé les éléments nécessaires se trouvant ailleurs...)
Je crois que j'ai fait le tour de ce qui me paraît le plus important en la matière. A l'époque de la bascule du système macro d'Excel en VBA [version Excel 5.0], Microsoft avait publié deux ouvrages, l'un reproduisant sous forme imprimée l'aide complète de VBA (et matériels et logiciels de cette époque, et aussi sans doute habitudes, faisaient qu'on allait plus vite à chercher dans l'aide sur papier que sur écran !), l'autre constituant un cours de programmation centré sur VBA, mais faisant une large place à la relation conception-programmation d'un projet : s'il est bon de savoir un peu comment on peut programmer au moment de la conception (ne serait-ce que parce que cela permet d'éliminer des directions de travail qui ne permettront pas d'aboutir dans de bonnes conditions dès le départ), on ne peut programmer efficacement que si la conception a été menée à son terme, si toutes les fonctionnalités du projet et leurs interactions ont été pensées, et même si les développements futurs sont présents en filigrane dans la conception du projet actuel...
On ne trouve plus, ou il faut aller les chercher ailleurs, ces considérations sur l'impact d'éléments qui ne relèvent ni d'Excel, ni de VBA, dans la réalisation d'un projet. En tout cas, j'insisterai toujours sur la primauté à apporter à la conception, avant d'écrire la moindre ligne de code. A cet égard, je dirais volontiers qu'une fois défini un processus, il est bon d'approfondir son fonctionnement pour qu'il soit le plus économique possible, et se référer aux souvenirs de maternelle, jeux pour trier, ordonner, compter... avec des bûchettes, gommettes ou autres support... Ce sont des types d'opérations toujours programmables en VBA, reposant sur des instructions simples et rapides et se traduisant souvent par plus d'efficacité. Si ensuite on se rend compte que des instructions plus complexes ou des fonctionnalités Excel peuvent être utilisées aussi efficacement par VBA et s'avèrent plus pratiques, une substitution peut être vite réalisée... mais sans zapper la phase précédente.
Un dernier conseil, tout à fait trivial
A un niveau plus individuel, il faut que celui qui programme s'y retrouve lui-même, donc cela peut reposer plus sur ses propres codes, références, analogies... personnelles. Et c'est sur cette base que je conseille des noms suffisamment explicites pour soi et suffisamment courts. Un nom de 3 caractères ou moins sera plus vite écrit qu'un nom de 15 caractères ou plus ! Lorsqu'on a à l'écrire 50, 100 fois ou plus dans un programme, cela devient très sensible, et je pense qu'il n'y a pas de petites économies en la matière, mieux vaut passer ce temps à autre chose, VBA sera aussi efficace avec des noms courts que longs.
Sur ce, cordialement et bonne journée.