Probléme de plantage à cause du code VBA

Question

Je reviens vers vous car j'ai trois problèmes qui sont très embêtant. Je m'explique: 1: J'ai un formulaire où il y a un plantage systématique de excel quand je rajoute dans un tableau une donnée. Cela me dit : "Une exception win32 non générée s'est produit dans EXCEL.EXE &#91;4680&#93;." Excel s’arrête et redémarre. 2: Le deuxième est que j'ai rajouté un bouton "Ajout de donné" au quel j'ai associé une code. Quand je lance mon formulaire et veux ajouté dans mes textboxs les nouvelles données qui vont s’enregistre dans les cellules correspondantes, ça plante. Cela me dit " Erreur d'exécution '-2147417848 (80010108)': La méthode '_Default' de l'objet 'Range' a échoué. Ici, je me pense que le problème viens de commande RANGE. Mais ce que je comprend pas, c'est que avant cela marché parfaitement. 3: Mon troisième est que pour le code suivant : If CB_Analyse.ListIndex = -1 Then Exit Sub ' Permet de sortir de la procédure si vous séléction rien (si le champs est vide) qui me permet que quand la combobox est vide d'avoir rien dans mes TB. Cette dernier ne fonctionne plus. Quand je sélection un choix et l'efface ce dernier, mes TB reste alors remplie. Avant le plantage, cela fonctionné. Je vous met le fichier excel en question. Pouvez-vous me dire si vous aussi vous avez ces plantages. Merci d'avance de votre aide...

thev · Answer

Cela est dû au fait que vous chargez votre ListBox à la compil via la propriété "RowSource". Dans cette configuration, Excel n'admet pas de modification de la source lors de l'exécution. Il faut charger votre ListBox à l'exécution via la propriété "List" et alors ajouter au dessus de la ListBox, un contrôle de type Label pour les entêtes de vos colonnes...

MFerrand · Answer

J'ai quelques hésitations à intervenir sur ton sujet ! D'abord parce que tu commences déjà à donner dans le gigantisme des formulaires, le tien ne peut s'afficher entièrement sur mon écran, c'est toujours quelque peu gênant pour travailler... (d'autant que lorsque la taille d'un formulaire dépasse le quart de la surface de mon écran, je trouve déjà qu'il ne remplit plus vraiment son rôle de facilitation de la saisie mais tend à la compliquer...) Ceci étant, comme il n'excède pas de beaucoup, je pourrai m'en accomoder, mais il va me falloir réorganiser le code pour pouvoir le travailler efficacement. Peut-être suis-je un peu atypique, mais je trouve que lorsque les procédures sont espacées d'une ligne vide et qu'on ne laisse aucune ligne vide à l'intérieur des procédures, on voit tout de suite mieux les éléments du code (ce que fait VBA lorsque l'on ne vient pas le perturber... ). Et de même, si on laisse VBA classer les procédures (oh ! il ne fait rien d'ésotérique, il les classe par ordre alphabétique !) et que l'on place celles qui ne programment pas des évènements que l'on peut être amené à rajouter, dans la zone (General), en tête du module, à la suites des déclarations s'il y en a, curieusement je trouve qu'on s'y retrouve beaucoup plus rapidement ! Et j'ajouterais que s'il y a peu ou pas du tout de commentaires, généralement tout à fait inutiles, cela n'en est que mieux, on ne perdra pas de temps à chercher le code au milieu des commentaires. Mais le code étant encore en volume réduit, cela devrait pouvoir être rapidement remis en ordre. Cependant, il reste nombre de points obscurs que j'aimerais éclaircir avant toute intervention, de même que clarifier le rôle du formulaire qui apparaît encore ambigu. Je ne vois le rôle de la feuille Liste qui ne fait que reproduire le tableau Source. Encore moins le rôle de Feuil1, vide et masquée. Côté formulaire, la ListBox LB_Analyse ne semble être là qu'à titre décoratif, auquel cas il vaudrait mieux se défaire des ornements dont on ne se sert pas ! C'est d'ailleurs peut-être elle qui te fait planter, étant alimenter par RowSource, à partir de la Source, lorsque tu veux modifier celle-ci... On a une Combo qui reprend ta colonne A de la source et à la sélection d'un élément, cela alimente les TextBox, OK ! il s'agit d'un dispositif de consultation mais que fait-on au-delà de la consultation ? Le contenu des TextBox ne disparaît pas lorsque tu effaces la valeur de ta Combo, tout simplement parce que ce n'est pas programmé... Mais lorsque tu as affiché un enregistrement de ta source, tu peux le reproduire dans la source en cliquant sur un bouton ! Il me semble que créer des lignes dupliquées pourrait n'être pas l'objectif à réaliser ! et qu'il y a peut-être à éclaircir les fonctionnalités du userform en fonction des objectifs rationnellement recherchés ? Si tu entends utiliser le formulaire pour gérer une base de données (ta source). Le dispositif en place permet au-delà de la consultation, de modifier un enregistrement et valider la modification. Le même permet aussi l'ajout d'un enregistrement (si la valeur de la Combo est dans sa liste, élément existant modifiable, si pas dans la liste élément nouveau ajoutable). Il y aura juste quelques compléments à faire au code, et bien sûr quelques rectifications... Mais l'objectif doit être clairement défini ! Il faut aussi indiquer le rôle des dates d'incubation et de lecture, ne constituant pas des champs de la source, et dont le rôle demeure tout à fait incertain. En guise d'aperçu : je supprimerai ta variable module Ws qui ne se justifie pas (quand on travaille avec des tableaux Excel, on s'en sert !), ton bouton Source dont la fonction est inutile (activer ou sélectionner ne fait jamais partie des choses à faire, sauf éventuellement en fin de parcours pour afficher...), ce qui entraînera des ajustements mais sur le fond, ce qui est à mettre en place dépend des éclaircissements à apporter. Cordialement...

thev · Answer

Ci-jointe proposition de correction avec 1- simplification du code via utilisation des propriétés et méthodes associées à l'objet tableau 2- modification de la colonne temps d'incubation avec des valeurs numériques et utilisation d'un format d'affichage. Edit: Je viens de voir le post de MFerrand. Il serait bon de tenir compte de ses remarques...

MFerrand · Answer

Je ne sais si tu as testé que l'erreur provenait bien de la ListBox... Je n'ai pas cherché à le faire, mais à l'expérience les probabilités plaident dans ce sens... Il y a de quoi faire quelque chose de cohérent avec le dispositif mis en place, mais il faudrait savoir où l'on veut aller exactement. Bon weekend...

thev · Answer

Pas eu besoin car pour l'avoir déjà expérimenté, je sais qu'Excel plante dès lors qu'on utilise la propriété Rowsource et que l'on modifie la source pendant l'exécution. Tout à fait. D'autant plus que Dashil prend soin de la lisibilité de son code...

thev · Answer

Ca marche si vous ne modifiez pas durant l'exécution , la liste chargée via RowSource. Sinon, Excel finit par planter...

MFerrand · Answer

Je ne pense pas que ce soit un bon choix. Tu t'interdis une utilisation efficace du tableau, qui te pemettait de largement simplifier ton code...

Mieux vaudrait supprimer la liste pour la réintroduire ensuite, dès lors que la ListBox sert à quelque chose, mais de plus comme en l'état elle n'a strictement aucune utilité, son existence ne se justifie en rien...

Mais tu peux faire tes expériences ! Cela te permettra de venir fréquemment exposer tes dysfonctionnements.

Je profite pour répondre à une de tes remarques. Il y a en effet depuis quelques années une assez grande diversité dans les manières d'écrire le code, ce que je ne cesse d'ailleurs de déplorer car cela conduit à passer beaucoup plus de temps pour le lire qu'il n'en faudrait. Effectivement, l'indentation telle que préconisée au départ, consiste à opérer des retraits : retrait initial du code intérieur à une procédure, qui ne laisse sans retrait que la déclaration (Sub... et End Sub) et les étiquettes de branchement (dont VBA supprime d'ailleurs automatiquement les retraits), et ensuite retraits du code inclu dans des instructions composées (type If... End If, With... End With, For... Next, etc), et retraits successifs lors d'imbrications d'instructions, ce qui aligne verticalement les éléments de ces instructions et permet d'un coup d'oeil de repérer un élément manquant ou de trop...

Quant à l'aération, si je suis obligé de scroller pour lire 10 lignes de code, je perds du temps, le fil et ça finit par m'énerver sérieusement, surtout quand certains codeurs arrivent à occuper 10 lignes en écrivant 3 lignes seulement mais en accolant les procédures les unes aux autres... Il y a un moment où je cesse de lire.

Microsoft avait édité un ouvrage sur la programmation VBA lors de sa mise en service avec Excel 5. Ce que j'applique c'est pour l'essentiel ce qui y était préconisé. Il m'est arrivé de m'en écarter mais à l'expérience j'y suis revenu en constatant que cela faisait gagner du temps et permettait un travail plus efficace sur le code...

Il y a certes toujours matière à personnaliser des modalités d'écriture du code, mais dès lors qu'un nombre minimal de règles et conventions sont observées, on sait où trouver quoi et on le trouve plus facilement : outre l'indentation, la déclaration des variables en début de procédure, le positionnement du code dans les modules (déclarations, procédures Function, procédures Sub), éviter tout terme du langage VBA comme nom de variable... Après, si on rencontre des particularités de style, elles ne gênent pas dès lors qu'on a un cadre dans lequel on peut aisément se retrouver, mais permettent alors parfois d'identifier l'auteur...

Cordialement.

thev · Answer

J'avoue ne pas comprendre ton obstination sur ce choix dès lors qu'une modification intervient sur la source. Ce sera toujours une mauvaise solution qui risque d'entraîner un dysfonctionnement. L'alternative via le chargement avec la propriété .List est quasi équivalente à ceci près qu'il faut ajouter un label de titres dans l'UserForm comme proposé dans mon envoi. Mais comme le dit MFerrand, il faut toujours faire ses propres expériences pour revenir au bon sens...

MFerrand · Answer

Juste pour t'éclairer sur la "béquille" (si je puis m'exprimer ainsi) que t'a tendue Thev (avec un objet source), mais dont tu peux te passer... et expliciter les remarques afférentes de mon premier post sur ton sujet. Un tableau Excel est un objet ListObject en VBA. On atteint cette objet par : Worksheets("NomFeuil").ListObjects(1) dès lors qu'il n'y a qu'un seul tableau Excel sur la feuille concernée (sinon mieux vaut utiliser le nom au lieu de 1...) Cet objet a une propriété .Range qui renvoie tout le tableau en tant que plage, et une propriété .DataBodyRange qui renvoie également une plage, mais excluant la ligne d'en-tête, et couvrant donc la partie données du tableau. Lorsque tu crées ton tableau Excel, l'application introduit automatiquement un nom dans le classeur, constitué par le nom du tableau, dans ton cas Tanalyse qui couvre la plage de données du tableau, soit équivaut à .DataBodyRange . Ce nom est utilisable en VBA de la même façon qu'un nom de plage. Autrement dit lorsque tu veux ajouter une ligne tu définis aisément la ligne d'insertion par : lni = &#91;Tanalyse&#93;.Rows.Count + 1 Et si tu prends la peine de constituer un tableau de tes données à affecter (au lieu de te précipiter pour les affecter cellule par cellule). With &#91;Tanalyse&#93; lni = .Rows.Count + 1 .Cells(lni, 1).Resize(, 7).Value = Tbl End With Tu affecteras en une seule fois ta ligne (sur 7 colonnes), immédiatement sous le tableau existant. Ligne qui sera automatiquement incorporée au tableau par Excel. (NB- un tableau à une dimension est un tableau horizontal) Pour tenir compte que tu peux démarrer avec un tableau vide, tu modifies légèrement la définition de la ligne d'insertion : lni = Iif(.Cells(1, 1) &lt;&gt; "", .Rows.Count + 1, 1) de façon à ne pas laisser une première ligne du tableau vide. De cette façon, tu n'as jamais à te soucier du nom de la feuille, tu n'as jamais à recalculer quelle ligne de la feuille doit être servie (d'autant plus que lorsque tu as un tableau Excel, End(xlUp).Row te renvoie la dernière ligne du tableau qu'elle soit occupée ou vide, tu vois donc à quoi tu t'exposes si tu laisses des lignes vides dans ton tableau...). Et si tu dois faire référence à la feuille, par exemple pour t'assurer que ton tableau n'est pas filtré et le défiltrer s'il l'est, tu y accèdes par : &#91;Tanalyse&#93;.Worksheet ou &#91;Tanalyse&#93;.Parent . Cordialement...

thev · Answer

MFerrand t'a apporté un premier éclairage. Tout d'abord, un objet tableau est créé à partir du menu --&gt; Insertion --&gt; bouton : Tableau. Son avantage notamment est que la plage de ses données est connue et que toute formule est répétée automatiquement en cas d'ajout d'une ligne. Au niveau VBA, ses propriétés et méthodes sont riches, ce qui simplifie le code. ListObject(1)? : réponse apportée par MFerrand ListRows.Count? : nombre de lignes de données du tableau et donc également numéro de la dernière ligne ListRows.Add (sans paramètre supplémentaire) : méthode ajoutant une nouvelle ligne vide à la fin du tableau Value? : 1) appliquée à une plage d'une seule cellule = valeur de la cellule, 2) appliquée à une plage de plusieurs cellules = tableau à 2 dimensions (ligne, colonne), chaque élément du tableau correspondant à la valeur de la cellule correspondante A noter que la propriété "List" d'un contrôle n'admet qu'un tableau. le point "." permet d'associer une propriété/méthode à un objet. Dans mon code, le point se rapporte à l'objet source via l'instruction With Pourquoi définir cet objet correspondant au tableau, tout simplement pour éviter de répéter n fois dans le code : Sheets("source").Listobjects(1). Car si jamais le nom de la feuille "source" est changé, un seul remplacement sera nécessaire...