Boucler sur objets d'un ou plusieurs Userform
fabien25000
Messages postés
697
Statut
Membre
-
yg_be Messages postés 23437 Date d'inscription Statut Contributeur Dernière intervention -
yg_be Messages postés 23437 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour à tous,
Merci d'avance à tous ceux qui prendront le temps de me lire et de m'aider à trouver des pistes de travail
J'ai un fichier excel qui fonctionne uniquement par formulaires.
tout fonctionne relativement bien mais j'ai parfois des "caprices", des bugs qui se manifestent sans raison apparente.. Le code fonctionne mais de temps en temps il se met en debogage et il suffit (souvent) de remettre la ligne jaune au début du sub pour que tout se déroule à nouveau correctement.
Je précise que toutes mes feuilles de codes ont le sésame "option explicit" et que le projet est compilé donc à priori, pas de variable sauvage qui se balade.
Mon idée pour essayer de comprendre ces "caprices" serait de faire un module rapport de bug, de boucler sur les uf actifs et en récupérer les valeurs et état de chaque objet. Mais chaque uf est différent ça peut aller de 3 objets à plus d'une centaine
Est ce qu'il y a une méthode pour rendre cette boucle générique indépendamment du nombre d'objet, de leur type (textbox, combobox, chekbox, optionbutton... etc) et de leur nom? un genre de code dans cette idée mais je n'arrive pas à trouver comment l'écrire
Etant un outil de vente qui comporte une centaine de feuilles, une vingtaine d'userform et autant de modules il m'est impossible de le partager ici sans données confidentielles
Configuration: Windows / Chrome 102.0.5005.63
--
Quand on ne dispose que d'un marteau tout les problèmes ressemblent à un clou
Merci d'avance à tous ceux qui prendront le temps de me lire et de m'aider à trouver des pistes de travail
J'ai un fichier excel qui fonctionne uniquement par formulaires.
tout fonctionne relativement bien mais j'ai parfois des "caprices", des bugs qui se manifestent sans raison apparente.. Le code fonctionne mais de temps en temps il se met en debogage et il suffit (souvent) de remettre la ligne jaune au début du sub pour que tout se déroule à nouveau correctement.
Je précise que toutes mes feuilles de codes ont le sésame "option explicit" et que le projet est compilé donc à priori, pas de variable sauvage qui se balade.
Mon idée pour essayer de comprendre ces "caprices" serait de faire un module rapport de bug, de boucler sur les uf actifs et en récupérer les valeurs et état de chaque objet. Mais chaque uf est différent ça peut aller de 3 objets à plus d'une centaine
Est ce qu'il y a une méthode pour rendre cette boucle générique indépendamment du nombre d'objet, de leur type (textbox, combobox, chekbox, optionbutton... etc) et de leur nom? un genre de code dans cette idée mais je n'arrive pas à trouver comment l'écrire
For Each ufactif In thisproject
For Each objet In ufactif
If objet Like Label Then Next objet
Worksheets("toto").Range("tata") = objet.Name
Worksheets("toto").Range("tutu") = objet.Value
Next objet
Next ufactif
Etant un outil de vente qui comporte une centaine de feuilles, une vingtaine d'userform et autant de modules il m'est impossible de le partager ici sans données confidentielles
Configuration: Windows / Chrome 102.0.5005.63
--
Quand on ne dispose que d'un marteau tout les problèmes ressemblent à un clou
13 réponses
Résumé de la discussion
Le problème porte sur un fichier Excel fonctionnant par formulaires et présentant caprices et bugs aléatoires, nécessitant une journalisation pour comprendre l’état des contrôles lors de l’exécution. Des propositions visent à boucler sur les UserForms en VBA et à récupérer les valeurs et états des contrôles, en utilisant une détection du type d’objet et en traitant les cadres imbriqués. Pour compléter, des solutions évoquées incluent l’utilisation d’un module JournalDeClic et d’un RapportDeBug pour collecter les clics et les propriétés des contrôles, avec une gestion d’erreur pour éviter l’interruption du programme. Enfin, il est suggéré de distinguer l’erreur critique qui oblige l’arrêt du flux d’exécution de l’erreur non bloquante et de prévoir deux branches de traitement selon le risque de bogue.
-
Bonjour,
un exemple de code pour lister les objets de plusieurs Userform si pas un label avec une seule procedure
https://www.cjoint.com/c/LFljK6JB7ig-
Bonjour et merci à toi pour ton retour
dans le sub tu déclaresDim Ctl As MSForms.Control
mais dans le code tu utilisesFor Each Ctrl In UF.Controls
variable déclarée Ctl et ensuite on trouve Ctrl. On est d'accord que ce n'est pas volontaire mais plutot une faute de frappe?
Pour utiliser ton exemple il faut appeler la procédure en donnant comme argument le nom de l'uf que l'on veut analyser, donc ne sachant pas d'ou vient le bug il faut prévoir l'appel dans chaque sub de chaque uf?
-
-
Bonjour
Un exemple pour avoir la liste des noms contrôles d'un userformPrivate Sub btok_Click() Dim s As String Dim OObj s = "" For Each OObj In Me.Controls s = s & OObj.Name & vbLf Next OObj MsgBox s End Sub
https://www.cjoint.com/c/LFljRgDtwYB
Cdlmnt-
Bonjour ccm81 et merci pour ton retour,
ton code est assez similaire au code de f894009
tu déclaresdim OObj
: quand on ne précise pas le As qqchose, une variable se déclare automatiquement en variant c'est ça? dans ton exemple on pourrait déclarerdim OObj As MSForms.Control
?
même question qu'à f894009 : ne sachant pas d'ou vient le bug il faut prévoir l'appel de ton exemple dans chaque sub de chaque uf?
-
-
yg_be Messages postés 23437 Date d'inscription Statut Contributeur Dernière intervention Ambassadeur 1 588
bonjour,
peut-être:Dim comp, ct As Control, s As String Debug.Print Now() For Each comp In ThisWorkbook.VBProject.VBComponents If comp.Type = 3 Then Debug.Print comp.Name For Each ct In comp.designer.Controls s = TypeName(ct) Select Case s: Case "Label": Case "TextBox", "CheckBox": Debug.Print ct.Name, ct.Value Case Else: Debug.Print ct.Name, s End Select Next ct End If Next comp-
Bonjour yg_be et merci pour ton retour
ton exemple si j'ai bien compris analyse l'intégralité du classeur, toutes les feuilles, et tous les uf ?s = TypeName(ct)
donne le type de l'objet (combobox, textbox etc)?
j'ai déjà luDebug.Print
(souvent dans les codes que tu partages d'ailleurs) mais je ne sais pas m'en servir et je ne vois rien à l'écran quand je passe la ligne au pas à pas ça fait quoi exactement?
J'ai aussi essayé d'appeler ta procedure depuis un uf (j'ai fait un bouton avec sur l'evenement du clic un call de la procedure) mais ça buggait sur la ligneFor Each ct In comp.designer.Controls
avec comme message "variable objet ou variable de bloc with non définie" mais en le mettant dans un sub qu'on déclenche avec F5 la boucle se fait correctement. Si je souhaite m'en servir à l'apparition d'un bug donc avec des uf ouverts ça va retourner le message d'erreur ou je m'y suis mal pris? -
variante:
Dim comp As UserForm, ct As Control, s As String Load UserForm1 Load UserForm2 Debug.Print Now() For Each comp In UserForms 'Debug.Print comp.Parent.Name For Each ct In comp.Controls s = TypeName(ct) Select Case s: Case "Label": Case "TextBox", "CheckBox": Debug.Print ct.Name, ct.Value Case Else: Debug.Print ct.Name, s End Select Next ct Next comp -
mon (ancien) code fait le tour de toutes les userform définies, pas de celles qui sont actives.
debug.print affiche dans la fenêtre "immédiate". ctrl+G pour activer cette fenêtre.
mon nouveau code devrait fonctionner sur les UserForms actives. -
ceci permet d'avoir aussi le nom du userform:
Dim comp As UserForm, ct As Control, s As String Debug.Print Now() For Each comp In UserForms For Each ct In comp.Controls s = TypeName(ct) Select Case s: Case "Label", "CommandButton": Case "TextBox", "CheckBox": Debug.Print ct.Parent.Name, ct.Name, ct.Value Case Else: Debug.Print ct.Parent.Name, ct.Name, s End Select Next ct Next comp -
effectivement ton nouveau code ne traite que les uf actives (et c'est top)
c'estFor Each comp In ThisWorkbook.VBProject.VBComponents
qui traite tout le classeur sauf les uf actives?ct.Parent.Name
Cette commande renvoie le "lieu" (je ne sais pas comment dire) où se trouve l'objet : si l'objet est sur l'uf ça renvoie le nom de l'uf mais si l'objet est dans une frame alors c'est le nom de la frame qui est renvoyé c'est bien ça?
L'objectif étant de récupérer les valeurs dans un rapport de bug et ne sachant pas où, ni quand un bug va apparaitre est-ce qu'il faut faire un appel de ton code dans chaque sub de tous les uf et de tous les modules ou il existe une autre méthode? je pense peut être à un public sub déclaré au démarrage du fichier. (j'ai essayé d'ecrireon error goto rapport_de_bug
en public juste après la ligne option explicit mais ça aurait été trop facile !)
Edit : je ne demande pas de précision sur ct.Parent.name pour que tu fasses une modif de ton code, vous m'avez déjà appris assez de chose pour que je réussisse à me dépatouiller de ça tout seul ;)
-
-
Bonjour et merci à vous 3 pour réponses instructives et extrêmement intéressantes
je vous répond chacun en commentaire sur vos postes respectifs ;)
-
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question -
yg_be Messages postés 23437 Date d'inscription Statut Contributeur Dernière intervention Ambassadeur 1 588
Je ne suis pas convaincu que ton approche (pour essayer de comprendre ces "caprices") va aboutir.
Le plus important, c'est d'obtenir le type d'erreur. Il est possible de l'obtenir via "on error".
Tu écris "il suffit (souvent) de remettre la ligne jaune au début du sub": tu as donc essayé de faire simplement F8, et cela ne suffit pas?
SI cela fonctionne en se remettant en début de script, cela ne signifie-t-il pas que ce ne sont pas les données (des userforms) qui causent le problème?
EDIT:
après une erreur (quand tu es dans le code qui traite unon error
,Err.Number
etErr.Description
te donnent le n° et le message d'erreur.-
Tu écris "il suffit (souvent) de remettre la ligne jaune au début du sub": tu as donc essayé de faire simplement F8, et cela ne suffit pas? oui F8 repete le message d'erreur et il m'est arrivé une fois par dépit, ne comprenant pas d'ou venait le probleme de remonter au début du sub et ça a fonctionné
cela ne signifie-t-il pas que ce ne sont pas les données (des userforms) qui causent le problème? oui je pense comme toi, mais comme quand mes commerciaux ont un bug ils sont incapable de dire ce qu'ils faisaient et ou ils ont cliqué quand c'est arrivé, j'ai pensé que le rapport de bug pourrait au moins régler ça et si en plus ça me permettait de comprendre ces "caprices" c'aurai été tout bénef
certains commerciaux arrivent à me faire bugger le fichier sur des routines écritent et qui tournent depuis 2 ans mais ils arrivent à débarquer dans mon bureau avec la fenêtre de debogage et sont incapable de me dire comment ils ont fait et même moi, je suis completement incapable de reproduire le problème (c'est encore arrivé il y a 1 heure sur l'uf où il n'y a qu'une liste deroulante pour choisir leur nom et 1 bouton valider pour passer à l'uf suivant)- Bonjour et désolé pour le retour tardif, j'ai eu un week end bien occupé.. j'ai tout de même eu le temps de réfléchir à nos échanges
je ne connais pas forcément le n° et le message d'erreur à vrai dire et c'est pour ça aussi que je me suis dirigé sur un système de rapport de bug :
soit les commerciaux sont avec des clients au magasin, et là si ils viennent dans mon bureau avec un bug, ma priorité est de faire le nécessaire pour "décoincer" le script et de faire en sorte que le fichier tourne jusqu'à l'édition du devis pour ne pas faire capoter la vente. Dans ce cas j'avoue que je regarde à peine le message d'erreur, je suis plus en mode "contre la montre"..
soit les commerciaux sont au domicile des clients et là, j'apprend le lendemain "qu'ils ont raté une signature à cause de mon logiciel qui plante" mais sans aucune indication sur ce qu'ils étaient en train de faire, où ils ont cliqué etc
Donc bien que je sois tout à fait d'accord avec toi sur le fait que le rapport risque de ne pas suffir à régler ce problème de "caprice" je continue à penser que ça pourrait rester utile pour me permettre de collecter des info en cas du souci.
D'ailleurs suite au bug que mon commercial a eu samedi sur un uf théoriquement impossible à faire bugger (une listebox et un bouton) j'ai pensé que plutôt que de récupérer les valeurs des objets de façon un peu brut, il y a peut-être plus d'interet de récupérer un "journal de clic"..? c'est à dire alimenter un tableau à chaque clic type "clic1-userform1-listbox1-valeur"toto"" qui s'ecrirait sur une feuille dédiée du classeur si on error est solicité
ça aurait au moins le mérite de reproduire exactement la situation du problème?
VBA permet pas mal de choses en debug: examiner les variables, par exemple.
je ne connais pas cet aspect de vba mais effectivement ca me semble indéniablement être un outils à maitriser. du moins je sais passer un code au pas à pas, utiliser les espions pour contrôler les valeurs des variables en temps réel (debug.print aussi maintenant que je vais m'appliquer à utiliser) mais je suis friand pour apprendre et m'améliorer en vba
-
-
Bonjour a vous deux,
Juste pour faire avancer le Schmilblik
Votre erreur n'est que dans une seule Userform?
Quand vous faites des essais chez vous (je pense que vous en faites), vous vous pouvez memoriser les mani que vous avez faites au moment de l'erreur. Vu que c'est vous qui avez fait cette "Application", devrait etre two fingers in the Nose
Quand vous avez l'erreur, click sur debug et passez le curseur souris sur les variables de cette ligne pour voir leur contenu
avant de remonter au debut de la procedure
Mettez un point d'arret sur la ligne dessous celle ou vous avez l'erreur
remonter au debut
relancer et faites la verifs des variables quand l'execution du code s'arrete
Si ca persiste et vous fait perdre des signatures, faudrait quand meme envisager de montrer votre fichier avec des donnees non confidentielles. C'est vous qui voyez-
Bonjour f894009
Votre erreur n'est que dans une seule Userform? Non, ils arrivent à faire planter le fichier n'importe ou et n'importe quand : un uf avec une listebox ou il faut écrire son nom (pour récupérer le nom du commercial pour l'edition du devis) et le bouton valider qui passe.enabled=true
sur_afterupdate
de la listebox si le nom est ok avec la liste proposée... (ça fait quasi 4 ans que j'ai écrit cette routine donc elle est largement éprouvée)
Quand vous faites des essais chez vous (je pense que vous en faites), vous vous pouvez memoriser les mani que vous avez faites au moment de l'erreur. Vu que c'est vous qui avez fait cette "Application", devrait etre two fingers in the Nose Oui je teste personnellement au maximum le nouveau contenu avant de le rendre disponbile et comme dit plus haut effectivement je me sert du pas à pas et des outils de contrôle des variables avec le passage du curseur et des espions pour vérifier que tout se passe comme je l'ai prévu mais visiblement c'est des sauvages qui cliquent tout azimute.
Quand il s'agit d'un bug dû à une mauvaise instruction je la repère et la corrige rapidement
En général les "caprices" arrivent plutot au publipostage, ça coince parfois à l'ouverture word, parfois à l'enregistrement du word en pdf après publipostage mais il n'y a pas de constante sur la ligne qui coince, sur le word utilisé, sur la feuille du classeur qui alimente le publipostage etc..
faudrait quand meme envisager de montrer votre fichier avec des donnees non confidentielles. C'est vous qui voyez Vous n'imaginez pas à quel point j'aimerai pouvoir partager mon travail et avoir un retour constructif dessus.. au delà des tarifs et infos confidentielles, mon fichier va chercher plusieurs centaines de photos (au moins 600 en tout) qui illustrent dynamiquement les choix cliqués en temps réels, il choisi quel word utiliser entre une vingtaine de fichiers pour le publipostage et donc tous les chemins sont écrits en "dur" dans mon programme et j'avoue que j'ai du mal à voir comment rendre le code neutre et utilisable par une personne externe mais dieu sait que j'aimerai que ça soit possible !
-
-
Re,
Sauf erreur de ma part, vous n'avez jamais precise le numero et le texte de l'erreur
La ligne en question fait quoi?
Pouvez montrer la ligne la ligne ou faites une copy d'ecran-
re,
ca plante pas forcément sur la même ligne c'est ça mon souci sinon j'aurai creusé dans ce sens. comme dit plus haut :
je ne connais pas forcément le n° et le message d'erreur à vrai dire et c'est pour ça aussi que je me suis dirigé sur un système de rapport de bug :
soit les commerciaux sont avec des clients au magasin, et là si ils viennent dans mon bureau avec un bug, ma priorité est de faire le nécessaire pour "décoincer" le script et de faire en sorte que le fichier tourne jusqu'à l'édition du devis pour ne pas faire capoter la vente. Dans ce cas j'avoue que je regarde à peine le message d'erreur, je suis plus en mode "contre la montre"..
soit les commerciaux sont au domicile des clients et là, j'apprend le lendemain "qu'ils ont raté une signature à cause de mon logiciel qui plante" mais sans aucune indication sur ce qu'ils étaient en train de faire, où ils ont cliqué etc
par contre ça m'a pris 4h mais je pense avoir passé mon classeur au crible pour permettre un envoi confidentiel et (normalement) j'ai mis en commentaire toutes les lignes qui comportent des chemins d'accès qui ne fonctionneraient pas ailleurs que chez moi
bien que ce soit un peu border line avec la charte de CCM, je préférerai l'envoyer en message privé une fois que je serai sûr que le destinataire habite assez loin de chez moi et qu'il n'est pas susceptible de franchir la porte de mon magasin
je suis désolé pour la démarche mais je tiens à mon emploi ;)
-
-
Re,
je suis désolé pour la démarche mais je tiens à mon emploi
Il en va de soi.
Vous dites que l'erreur apparait de n'importe quelle Userform, mais est-ce dans une procedure utilisee par toutes ou une par Userform
sûr que le destinataire habite assez loin de chez moi
Passez par la messagerie perso et dites d'ou vous etes je ferai de meme.
Pour ce qui est de la confidentialite, aucune crainte de ce cote-
(message privé envoyé)
Mes commerciaux sont des magiciens qui arrivent à faire ressortir des bugs littéralement n'importe où, n'importe quel uf, n'importe quelle procedure mais quand ça arrive ils sont incapable d'expliquer sur quel événement/bouton/clic c'est arrivé
ce ne sont pas des bug récurrents ils arrivent tout de même à bosser assez sereinement (plus de 1200 devis l'an dernier avec mon fichier) mais je ne suis jamais à l'abris d'un tour de magie et d'un bug improbable sur des routines largement éprouvées par le temps
d'ou mon idée d'éditer un rapport de bug afin de comprendre comment ils en sont arrivés là -
Si tu ne peux pas reproduire le problème, je ne vois pas trop l'utilité, pour l'instant, de mettre à disposition un fichier qui, de plus, ne contient peut-être pas le "défaut" du fichier originel.
Peut-être demander aux utilisateurs de prendre une capture d'écran avec le message d'erreur puis avec l'endroit du souci dans le code?
Un bug intermittent peut aussi venir de l'environnement, pas de ton code. -
C'est le fichier originel que j'ai envoyé, j'ai retiré tous les tarifs, les logos et mis en commentaire les chemins de sauvegarde et de recherche de photo, c'est la seule différence avec le fichier qu'utilisent mes commerciaux.
Ce qui m'intéresse aussi (c'était pas prévu) c'est d'avoir un avis global sur mon travail
un bug peut venir de l'environnement c'est un peu ce que je redoute... Il y a une manière de contrôler ça? -
-
-
-
Voilà sur quoi je m'oriente pour l'instant :
dans le module qui me sert de module Général (celui qui regroupe des procédures qui peuvent être appelées depuis plusieurs userforms) :Option Explicit Public z As Long Public TabJournal(500) Sub JournalDeClic(uf As UserForm) z = z + 1 Select Case TypeName(uf.ActiveControl) Case "Label", "CommandButton": TabJournal(z) = "Clic " & z & " sur : " & TypeName(uf) & ", objet : " & TypeName(uf.ActiveControl) & ", nom : " & uf.ActiveControl.Name Case "TextBox", "CheckBox", "OptionButton", "ComboBox": TabJournal(z) = "Clic " & z & " sur : " & TypeName(uf) & ", objet : " & TypeName(uf.ActiveControl) & ", nom : " & uf.ActiveControl.Name & ", valeur : " & uf.ActiveControl.Value Case Else End Select End Sub Sub RapportDeBug() Dim x As Integer x = 1 Worksheets("Bug").Range("A1").Value = "Erreur n° : " & Err.Number & " : " & Err.Description Do Until TabJournal(x) = "" Worksheets("Bug").Range("A" & x + 1).Value = TabJournal(z) x = x + 1 Loop End Sub
Et je compte rajouter ça à chaque sub (ça va faire du taf..!) :Private Sub lbLoggin_Enter() On Error GoTo fatal Call JournalDeClic(ufLoggin) ' ' 'code "normal" ' ' Exit Sub fatal: Call RapportDeBug End Sub
Ca vous semble cohérent ou je suis à côté de la plaque?
-
Bonjour à vous
je suis désespéré, il n'y a rien qui va comme je voudrais
j'utiliseTypeName(uf.ActiveControl)
pour récupérer le nom de l'objet dans mon "journal de clic" sauf que si l'objet est dans une frame par exemple, au lieu de renvoyer le nom de l'objet, ça renvoie le nom de la frame donc je n'ai pas de tracabilité des clics
+ en faisant ces tests, je me rend compte que le on error empêche la fenêtre de débogage d'apparaitre. Sur un bug "mineur" par exemple un set focus non accessible, c'est bien puisque ça ne gêne pas la suite du programme mais sur un "gros" bug par exemple aller chercher un word qui n'existe pas au chemin indiqué, il faut que le programme s'arrête puisque la suite du programme ne pourra pas s'executer et surtout que l'utilisateur soit prévenu de l'impossibilité de continuer
Est ce qu'il y a un moyen de différencier un bug qui n'affecte pas la suite du programme d'un bug qui plante totalement la suite des opérations?
-
peut-être désactiver la gestion d'erreur et recommencer le traitement qui a causé l'erreur:
fatal: Call RapportDeBug On Error GoTo 0 Resume End Sub- j'ai essayé.. et j'ai pas compris sur quelle piste tu voulais m'envoyer
en écrivant ces 2 lignes, ça va dans rapportdebug qui fait bien son boulot, mais après ça retourne sur l'erreur et du coup la fenêtre de debug s'affiche
j'ai essayé resume next à la place de resume : ça va bien sur l'erreur de set focus que j'ai créé sur un bouton en visible=false mais sur l'erreur du word qui n'existe pas (que j'ai écrit pour symboliser une erreur empêchant le code de se poursuivre) là par contre le next ne sert à rien ce que je comprend mais qui ne m'avance pas.. A moins de re-refaire encore un on error goto qui appellerai une sub avec un message et la fermeture du fichier? ça se fait ça?
-
-
Bonjour,
aller chercher un word qui n'existe pas au chemin indiqué
tester avant qu'il existe par ex:
Ok=Dir(chemins & Fichier)
Si Ok<>"" alors on continu sinon message et sortie-
Bonjour f894009
oui le word qui n'existe pas c'était juste un exemple, je ne savais pas trop comment déclencher une erreur volontairement pour voir si ce que j'écris faisait bien ce que j'attendais donc j'ai modifié le nom d'un word.
Logiquement dans mon fichier ces noms sont écrit en dur donc ça n'arrive pas, mais si le programme trouve un bug avec les mêmes conséquences comment le différencier d'un bug sans conséquences et comment le traiter (je n'ai pas encore mis en application la réponse de yg_be)
j'avoue que je suis un peu perdu avec les on error, j'essaye de me documenter mais c'est encore très flou et du coup je pinaille
et surtout je suis démoralisé par ceTypeName(uf.ActiveControl)
qui ne renvoie pas ce que j'attends et pareil, je ne trouve pas de solution.. c'est pas mon jour !
-
-
Re,
différencier d'un bug sans conséquences et comment le traiter
Ben, c'est vous qui definissez en cas d'erreur la suite a donner au niveau du code.
Si l'erreur compromet le deroulement du code pour arriver a un resultat "normal" vous devez prevoir un sortie qui permet de repartir sans enregistrement de quoi que ce soit en prevenant qu'il y a eu erreur majeur ou de continuer en acceptant un certain dommage
ex:n = UserForm1.Frame1.ActiveControl.Name
Il faut le nom de la Frame pour avoir le nom du control Actif
C'est pareil pour Typename
Vu que dans votre application il n'y a pratiquement que des frames ,voir des frames dans une frame, va pas etre simple a ficeler.
Ceci evidement en plus des erreurs liees au objets UF
Jusqu'ici, je n'ai pas eu d'erreur VBA de quoi que ce soit liee au code. pour la partie edition peut pas tester.
Je vais regarder si je peux adapter pour continuer sinon je destroye votre fichier.-
c'est vous qui definissez en cas d'erreur la suite a donner au niveau du code
selon dans quelle sub ou quel module, connaissant le degrès d'importance du risque de bug je dois donc faire 2 sub différentes et appeler soit l'une qui reporte le bug sans interrompre le programme et l'autre qui prévient et ferme le fichier c'est ça
va pas etre simple a ficeler
le plus simple que j'ai trouvé pour l'instant est de rajouter en paramètre le nom de l'objetSub JournalDeClic(uf As UserForm, Objet As String)
Ceci evidement en plus des erreurs liees au objets UF
pas compris la phrase
Je vais regarder si je peux adapter pour continuer sinon je destroye votre fichier
Super merci beaucoup d'avoir pris le temps de regarder, tenez moi au courant
-
-
Bonjour !
le rapport de bug est en service, il n'y a plus qu'à attendre pour voir ce qu'il en ressort.
f894009 que je remercie encore a pris le temps de parcourir mon fichier mais n'a relevé aucun bug dû au code en lui même si j'ai bien compris
l'objectif est donc maintenant de se tourner vers les problèmes d'environnement que yg_be mentionnait la semaine dernière :
comment ça se décèle? comment ça se traite?
f894009 m'a dit que mes lignes de codes pouvaient être rafraichies par des instructions plus récentes qui auraient le mérite d'améliorer les temps d'exécutions : est que c'est un paramètre qui peut jouer sur les problèmes d'environnement?
Merci d'avance pour les pistes de travail que vous pourrez me fournir
