Boucle While
Bonsoir,
Est-ce qu'une âme charitable pourrait m'aider à résoudre ce problème?
Pourquoi VBA ignore la boucle While?
D'avance merci pour vos réponses!
Salut titietdidi ,
tout simplement parce que ta variable "FinLigne" n'est pas initialisée et qu'elle vaut donc zéro.
NumeroLigne est donc toujours > FinLigne : 100.000.000.000 de While n'y changeront jamais rien!
Long est le chemin du VBA!
A+
Bonjour, Bonjour Curulis,
Effectivement, mettre en condition de sortie de boucle une variable non initialisée (et par ailleurs non déclarée), il n'en faut pas plus pour ne plus pouvoir sortir de la boucle...
Mais s'il n'y avait que cela, ce ne serait qu'une erreur bénigne de débutant à côté du volume d'erreurs concentrées dans un aussi petit nombre de lignes de code !
Il y a d'abord les variables, qui ne sont pas toutes déclarées, il est recommandé de ne pas faire d'exception et de déclarer toutes ses variables, pour une meilleure tenue et une plus grande efficacité du code.
Mais de plus elles sont déclarées (celles qui le sont) un peu n'importe où, là encore il est recommandé de déclarer ses variables en tête de procédure, toujours, avant tout code exécutable, ce qui permet à VBA de commencer par les mettre en mémoire...
Mais pour améliorer encore la chose, les deux variables déclarées le sont à l'intérieur de la boucle ! Burlesque ! On va donc les redéclarer à chaque tour de boucle... !
C'est aussi sans doute pour agrémenter un peu plus qu'une variable ne pouvant prendre manifestement que des valeurs entières est déclarée de type Single !
Entrons dans la boucle, deux expressions font appel à Range... de quelle feuille ? L'absence de qualificateur d'objet est la marque d'un code approximatif...
Cette approximation est en tant que telle sans conséquence autre que ralentir VBA tant que la feuille active correspond à celle sur laquelle on est censé opérer...
Par contre, pour Range(NumeroLigne), sans colonne, cela devient plus problématique !
La problématique va d'ailleurs quelque peu se compliquer car si la cellule dont la position est incertaine (et en tout cas pas définie) n'est pas vide, on déplace la sélection d'une colonne vers la droite, sélection dont la position au démarrage de la macro est tout à fait aléatoire car apparue nulle part avant cette première mention. Aïe ! Il faut s'attendre à des résultats quelque peu inattendus tant que l'éxécution n'est pas interrompue par une erreur fatale !
On peut tout de même prévoir qu'avec un cheminement vers le bas de la boucle et un déplacement toujours vers la droite de la sélection pour générer sur la même ligne (laquelle ?) des inscriptions successives, on aura parfaitement réussi à dissocier les inscriptions des éléments censés y donner lieu...
Je ne sais pas si le fameux Range(NumeroLigne) est susceptible de se traduire par une erreur d'eexécution... Avec Cells, il est sûr que non, on suivrait l'ordre de succession des cellules qu'Excel utilise par défaut. Il est donc bien possible que cela fonctionne de la même façon avec Range. Dans ce cas, c'est le déplacement vers la droite de la sélection qui bloquera une fois atteinte la colonne XFD, la dernière. Ce qui garantit que le nombre de tours de boucle ne pourra dépasser 16384 (un peu moins selon la position initiale de la sélection) !
Au-delà des errements du codage, il faut tout de même souligner encore que la présence de Select (ou autre Activate...) dans un code dont la finalité n'a pas de rapport direct avec l'affichage est l'indice indéniable d'un mauvais (inutile de chercher un autre qualificatif, c'est mauvais parce que imprécis et handicapant pour l'exécution) code !
Il n'y a pas lieu non plus dans ce contexte de s'étonner que le code ne soit pas indenté... Je suis toujours stupéfait de voir des classeurs, bien structurés, parfaitement présentés... et dès qu'on bascule dans l'éditeur VBA, c'est n'importe quoi ! Tout à fait analogue aux restaurant cliquants et paraissant de haut standing lorsqu'on pénètre dans la salle, mais où il vaut mieux ne pas aller jeter le moindre coup d'oeil dans les cuisines !
Il conviendrait que les débutants prennent conscience que le soin à apporter à la présentation du code doit être égal sinon supérieur à celui qu'on apporte à la présentation des tableaux.
Ce n'est d'ailleurs pas qu'une question de présentation. Comment indenter correctement si on ne sait pas la signification de ce que l'on écrit... Et puis quel intérêt que l'on puisse voir d'un seul regard toute la structure d'un code si on laisse ce soin à d'autres !!!
Je saurais gré aux demandeurs d'aide de se rendre compte que (car je n'imagine pas être seul à trouver parfois très déprimant de seulement regarder un fragment de code...) que la motivation d'aider des intervenants est principalement alimentée par les progrès visibles des demandeurs... Lorsqu'on n'en constate pas, il faut bien trouver d'autres motivations, plus personnelles, pour continuer à intervenir... Et tant pis si les demandeurs auront plus de mal à s'y retrouver !
Cordialement.
Bonjour MFerrand
Merci d'avoir pris le temps de me répondre !
Si je me suis inscrite sur un forum d'entraide, c'est bien évidemment car j'ai des difficultés! Je n'ai suivi que 3 cours VBA/Excel et on me demande de créer une banque en ligne alors veuillez m'excuser pour mes indénombrables fautes.Nous ne sommes pas tous des passionnés (et des pros) en 'informatique.
Bien à vous.
Bonsoir,
Débutante ou pas, quand tu viens sur le forum poser une question, la question elle-même, la façon dont elle est posée, l'ensemble des informations fournies, sont indicatives du type de réponse attendue.
Tu poses une question sur le dysfonctionnement d'un code (ou plutôt le non fonctionnement car il n'a jamais dû fonctionner), tu cites le code dont tu attends que l'on puisse te dire ce qui l'empêche de fonctionner comme prévu, tu ne fournis pas de fichier.
Donc tu attends une simple réponse littérale, mettant en évidence l'élément fautif ou manquant, à partir de laquelle tu entends faire ton affaire de la remise en état fonctionnel de ton code.
Curulis t'a répondu sur la question telle que tu l'avais posée, orientée sur la boucle. En voyant la discussion au passage, j'ai noté que sa réponse, tout à fait pertinente, ne te permettrait toutefois pas de rétablir un code fonctionnel, en raison de quelques autres éléments... (Je précise que je n'en ai pas vu la totalité au premier coup d'oeil, il m'a fallu simuler le déroulement de l'exécution pour percevoir ce qui devrait éventuellement se passer.)
Lorsque je décide de répondre à une question ou d'apporter une contribution, je ne manque en principe jamais, sous une forme ou une autre de signaler les défauts d'indentation et autres éléments d'écriture, de même que l'absence d'utilisation de la balise Code dans le forum. C'est un souci que certains trouvent sans doute excessifs, mais je considère qu'au premier abord la présentation du code manifeste la considération du demandeur pour les intervenants appelés à lui répondre, et je n'apprécie guère qu'on me balance du code comme on jette un os à un chien. En 2e approche, il ne s'agit pas d'un simple problème de présentation, cela joue un rôle non négligeable dans la production d'un code rationnel et efficace. Cela fait partie des apprentissages de base et il me paraît important d'inciter les néophytes à s'y astreindre, car cela accroîtra plus rapidement leur capacité à comprendre le code qu'ils écrivent et à progresser en matière de programmation. Je tiens compte du fait que ce n'est pas inné et qu'un débutant ne s'en souciera pas spontanément si on ne le lui dit pas. Je le dis donc, et le répète... en escomptant un effet positif à terme. (De toutes façons, si je suis amené à constater au bout d'un temps raisonnablement suffisant que mes propos en la matière sont sans effet, le demandeur concerné viendra tout naturellement s'ajouter à la liste de ceux auxquels je ne réponds plus aux questions, sans m'en porter plus mal !
Si un code ne présente pas un minimum de caractères de qualité qu'on doit en attendre, je ne vois pas de raison de ne pas en faire état le plus directement possible, sous peine de perdre du temps, là tout à fait inutilement. Mieux vaut balayer et reconstruire sur des bases un peu plus solides. Mais je ne me contente pas de le dire, j'explique en détail pourquoi telle façon de faire est mauvaise, ou pas optimale, ou pas recommandée ou déconseillée... Et en ce qui concerne les défauts fonctionnels je les pass également en revue, aussi exhaustivement que je le peux. Cela me paraît nécessaire pour fournir au demandeur les éléments qui lui permettront de faire autrement ou autre chose...
Alors, il se peut que certains de mes propos puissent ne pas être agréablement perçus ! Ce n'est d'ailleurs pas leur but. Mais si l'intéressé prend la peine de les lire avec attention il y trouvera tous les éléments pour analyser le problème qu'il a posé, le voir éventuellement sous un autre angle et parvenir à une solution si celle-ci découlait de l'analyse... En outre tu ne trouveras jamais dans mes propos des critiques acerbes sur des points relevant de la connaissance d'Excel à un niveau dépassant les bases élémentaires, ou relevant de la connaissance de VBA. Elles le seront par contre un peu plus sur les points relevant de raisonnements logiques ne reposant sur aucune connaissance ni en Excel ni en VBA.
Bref !
Cordialement.