Bonjour à tous,
Tout d'abord je tiens à préciser que je suis complètement débutant en VBA, mais ce problème là me retombe dessus quand même    
 
Pour la petite histoire, mon entreprise utilise un Excel pour faire des recherches de produits en magasin dans un fichier Excel.
Ce programme a été développé en version 2003 par, manifestement, quelqu'un qui connaît fort bien le VBA, mais qui ne fait plus partie du personnel.
Une feuille Excel avec quelques paramètres, paths, lance le programme (balèze). Ce programme ouvre une user form pour la recherche, un autre classeur excel qui contient les articles magasin et encore un autre classeur pour faire des tris et récupérer les critères de recherche.
 
Bien que plutôt compliqué, ce programme a fort bien fonctionné pendant des années... Sauf que nous venons de migrer le site en Win7 + Office 2013...
 
Premier bug : impossible de lancer le programme.
Impossible également d'accéder au code source, protégé par un mot de passe inconnu. J'ai donc du commencer par le cracker.
Solution du premier Bug : après ouverture d'un nouveau classeur l'appli cherchait à en renommer les 2 premières feuilles. Possible en Excel 2003 qui en ouvre 3 par défaut, mais impossible en Excel 2013 qui n'en ouvre qu'une. J'ai donc juste rajouté un "Sheets.Add" et ça roule.
 
Second bug : l'application semble maintenant fonctionner parfaitement (ouf). Par contre les principaux utilisateurs me remontent de fréquents plantages avec une Erreur 9... De mon côté impossible de reproduire le phénomène (pratique).
A force de persévérance je fini par y arriver en "stressant" le programme. Nombreuses sélections dans la liste de résultats, affichage des photos des produits etc...
 
Finalement j'isole le problème dans une sub qui permet de sélectionner un classeur et une feuille dont le nom est passé en paramètre. En effet, le programme semble passer sont temps à switcher entre les classeurs et les feuilles, cette sub est utilisée des centaines de fois.
 

 
Là où ça devient marrant (en fait là ça ne l'est plus, ça fait trop longtemps que je cherche...), c'est que si je met un point d'arrêt dans la routine d'erreur, je constate que ça coince sur "Sheets(Feuille).Select". Je constate également que le paramètre est bon et que classeur + feuille existent bien et ont déjà été sélectionnés des dizaines ou centaines de fois par cette même sub.
Encore plus fort, j'ai réinséré l'Activate et le Select dans la routine d'erreur. Une fois le programme planté en mode runtime, je continue le traitement en pas à pas et ça fonctionne au poil !  
Si je lui fait essayer plusieurs fois en runtime ça plante. Si je tente de temporiser un peu le nouvel essai, ça plante aussi...
 
Bref, j'en déduis que j'ai un problème de gestion mémoire ou un truc similaire qui fait que le select ne trouve pas la feuille qui est pourtant bien là...
J'en déduis également que passer en mode débug puis continuer en pas à pas doit justement réinitialiser le truc qui va bien, ce qui fait que le programme se déroule de nouveau normalement.
Je constate qu'on n'avait pas ce problème en 2003 et qu'on l'a en 2013. On aurait pu supposer la gestion mémoire mieux foutue en 2013. Même si le programme n'a pas été conçu de la meilleure manière qui soit (je suis bien incapable d'en juger), ça tournait très bien avant.
 
Alors du coup : HELP ?  

 
            Bonjour,
 
            je n'évoquerais pas forcément de bug mais des soucis …
 

            Pas de bug …
            Protéger l'accès au code en entreprise est normal afin d'éviter des modifications inopportunes par un utilisateur lambda.
            Ce qui ne l'est pas, l'entreprise étant propriétaire de l'applicatif, un responsable doit détenir le mot de passe …
            Quant au nombre de feuilles, c'est le paramétrage d'Excel dans ses options, B-A-BA de son utilisation !
            En modifiant son paramètre, il n'y aurait pas eu besoin de modifier le code …
 

            A mon avis, il ne connaissait pas fort bien le VBA, juste un bidouilleur, un bon code doit éviter les sélections à tout va !
            P'tite leçon à lire …            Et donc la procédure SelectFeuille aurait dû être évitée, n'a pas vraiment lieu d'être …
 
            Exemple d'accès à une feuille sans sélection grâce à une variable objet,
            copie de valeurs dans la feuille active de données de la feuille Références d'un autre classeur Catalogue :

            Pour moi, l'applicatif est à revoir dans sa globalité, limite de repartir d'une page blanche …
 
            Depuis la rupture de la version 2007, VBA évoluant vers VB.Net mais perdant au passage certaines instructions,
            développer exige de la rigueur …
            On s'est aperçu que les mauvais programmes ou tout simplement ceux générés par l'Enregistreur de macros
            pouvaient s'exécuter bien plus rapidement sous Excel 2003 que dans les versions ultérieures !
 
            Depuis la version 2010, Excel peut être installé en 64 bits pouvant utiliser plus de RAM, utile pour les classeurs énormes,
            mais perdant aussi des ActiveX (Microsoft ne les ayant pas tous convertis) et posant des soucis aux fonctions externes
            comme les API Windows par exemple (là Microsoft a fini par publier une notice …), obligeant certains de réinstaller Excel en 32 bits.
 
            Excel 2007 s'est bien fait cassé lors de sa sortie côté VBA.
            Lors du passage de codes de 2003 en 2007, je rencontre vraiment peu de soucis,
            soit une instruction disparue mais facilement contournable,
            soit une fonctionnalité modifiée dans son comportement mais le code est aisément corrigeable.
 
            Et depuis les versions 2010 et 2013, sur des forums du monde entier, je constate encore plus de choses négatives
            mais est-ce vraiment des soucis ou des développeurs mal formés ?
            Lorsque je réponds sur divers forums, souvent mon PC de tests est en version 2003
            et à 95% il n'y a pas de souci sur les versions ultérieures des demandeurs …
 
            Une position étant souvent précaire en entreprise, ne pouvant - ou ne voulant - pas se débarrasser de cette charge,
            demander une formation serait judicieux !

Merci pour cette réponse intéressante.
 
En effet le premier souci aurait pu être réglé différemment. Mais pour éviter une intervention sur le paramétrage de l'Excel de chaque utilisateur potentiel, j'ai préféré modifier le code.
De toute manière j'aurais été obligé de le cracker pour voir d'où venait l'erreur... J'ai moi même été très surpris que personne n'en ai eu connaissance dans l'entreprise, bref.
 
Le code me semble assez bien documenté, complexe et fignolé, ce qui me fait dire que le type qui a fait ça s'y connaît beaucoup mieux que moi ! J'ai vu de la vraie "bricole", là on est largement au dessus. Après tout le monde n'est pas expert...
Je me garderai bien de critiquer étant moi même un grand débutant en VB.
J'avais cependant cru comprendre, au cours de mes recherches, que cette sub n'était peut-être pas une bonne idée...
 
Il est cependant hors de question de reprendre entièrement ce code, je n'ai ni les compétences ni le temps pour ça. De plus j'ai des dizaines d'utilisateurs mécontents (il est même pas de moi ce programme mais ça me retombe dessus), il me faut une solution rapide même si elle n'est pas super élégante...
Pour cumuler les soucis potentiels, je préciserais que nous sommes en Office 2013 sous Win7 x64... Et ça ne peut pas être changé.
 
Mon idée, certes pas très élégante, était de rajouter, dans la routine d'erreur par exemple, une fonction pour libérer la mémoire ou je ne sais quoi et réessayer la sélection avant de continuer le programme.
Reste à trouver une idée de quoi faire, ou savoir ce qui se passe quand le programme passe de runtime à débug, sans pour autant interrompre l'exécution. Vu qu'une fois passé en débug ça fonctionne de nouveau.
Ca fait très "rustine" mais bon...
 
Je projetterai sans doute, un peu plus tard, de reprendre ceci en Access qui me paraît, à priori, plus adapté à ce genre de problématique.

Pas d'idée pour une "rustine" ?
Y a t-il un moyen de savoir ce qui "charge" le programme ? J'ai bien peur qu'une autre fonction soit la vraie cause du problème et cette bizarrerie un simple dommage collatéral.

 
            Une rustine est envisageable sur une chambre à air en cas de petit trou bien net, pas lorsque le flanc est déchiré …
            Donc pas de rustine possible pour un mauvais code !
 
            Désactiver la gestion d'erreur - ou pas - puis utiliser des points d'arrêt et/ou suivre le code en mode pas à pas via la touche F8 …
            Voir aussi la valeur des variables dans la fenêtre Variables locales …
 
            Questions à se poser :  à quoi sert précisément cette gestion d'erreur ?  Est-elle contournable ?
 

Le pb c'est qu'en pas à pas ça fonctionne parfaitement.
Les variables sont correctes au moment où ça bug pourtant.
 
Cette gestion d'erreur ne sert pas à grand chose si ce n'est à préciser la fonction qui génère l'erreur 9.
Elle me sert également, du coup, à mettre un point d'arrêt. Elle peut être utilisée des centaines de fois avant de planter, je ne pourrais pas mettre le point d'arrêt dans la fonction elle même.
 
Je l'ai déjà désactivée, j'ai toujours une erreur 9 au bout d'un moment, sauf que c'est le système qui m'ouvre un popup.

 
            Cette erreur provient généralement d'un problème de conception, une référence hors bornes, bref quelque chose d'inexistant …
 
            Tout dépend de la ligne déclenchant l'erreur …
 

Toujours le sheets.select
Vérifié en pas à pas, la feuille existe. Sa sélection a déjà été faite des centaines de fois quand ça plante.
Programme en fonctionnement normal il ne trouve pas la feuille, si je lance les instructions en pas à pas il la trouve...

 
            Sans voir au minimum la ligne complète mais bon, soit la feuille appelée n'existe pas (facilement contournable)
            soit c'est une saturation mémoire de la pile et là c'est donc la conception du code à revoir intégralement !
 

Pour moi il est clair que c'est une saturation mémoire. Il faut "stresser" le programme pour le faire planter.
La feuille existe bien c'est sûr et certain.
 
Quand on met un point d'arrêt, je ne sais pas ce qui se passe, mais ça réinitialise certainement le truc qui va bien, vu qu'après il retrouve ses esprits.
Ce qui me surprend c'est qu'il ne met pas d'erreur mémoire.
Egalement ça a toujours bien fonctionné en office 2003 sous XP 32bits, même si le code n'est pas top.
 
Du coup si j'arrivais à faire la même chose que le point d'arrêt, disons dans la routine d'erreur, ça permettrait de lui remettre les idées claires les quelques fois où ça plante, sans stopper l'exécution du programme.

 
           J'ai quand même un doute si la feuille existe sur le classeur actif …
 
           L'idéal étant de prendre son temps, de désactiver la gestion d'erreur
           puis de vérifier pour toute erreur sa source dans la ligne la déclenchant …
 

Le code est dans mon premier message.
 
La gestion d'erreur permet simplement d'afficher un message précisant dans quelle sub ça s'est produit.
En mettant un point d'arrêt à ce moment là, ça me permet de contrôler les paramètres passés à la fonction au moment où ça a planté.
Les paramètres sont bons, la feuille existe. D'ailleurs c'est un classeur qui est crée au lancement du programme, on n'y touche plus ensuite, on ne fait que zapper entre les feuilles.
 
Pensant à un problème de rapidité d'exécution, j'ai d'abord mis une pause dans cette gestion d'erreur puis réessayé le select = ça marche pas en fonctionnement normal, mais ça marche en pas à pas.   Donc les paramètres passés sont bien corrects et la feuille existe bien, je n'ai pas eu la berlue.
 
Le fonctionnement du programme fait réellement bugger Excel... Mais ça n'indique pas pour autant un problème de mémoire.  
 
En tous cas merci de te pencher sur la question

 
            Un bon code est sans  Select  comme dans la p'tite leçon en lien et dans le code en exemple de mon premier message …
 
            Et cela ne date pas des versions 2007 et postérieures, cela a toujours été ainsi !
            Du reste je suis assez surpris qu'il n'y avait pas de souci en 2003 car j'en ai déjà vu même dans des versions antérieures …
 

J'ai bien compris, pas de Select.
Mais ce programme est une usine à gaz très utilisée, il est hors de question de reprendre de zéro à court terme, pas de dispo ni les connaissances pour ça.
D'où mon souhait de trouver une "rustine" en attendant

 
            Je ne vois rien car une telle procédure n'a pas lieu d'être pour sélectionner une feuille existante !
 
            Les rares fois où j'ai croisé des cagagues et autres carabistouilles de ce genre j'ai été obligé de revoir le code,
            non pour me faire mousser mais tout simplement pas d'autre choix pour un code propre & stable …
 
            Peut-être qu'un autre intervenant aura quelque chose à proposer …
 

 
Bonjour,
 
Mon tout premier post chez vous! ça me fait chaud au cœur
 
j'ai rencontré le même problème que notre camarade avec une petite subtilité:  
Mon code fonctionnait parfaitement en excel 2007 sur poste lourd (pc classique), MAIS le même code ".select" me provoquait une erreur 9 sur mon profil "léger" citrix lui aussi en excel 2007. Dans le debug il m'indique que la source de l'erreur est "eurotool".  
Du coups j'ai suivi la logique et vos bons conseils et j'ai viré les derniers select que j'avais
j'ai remplacé les  
         

par

 
 
Sinon voila une rustine très moche pour gysmo_15 en attendant de mieux régler le problème de son côté.
Juste avant chaque lignes de select tu ajoutes:
 

Je répète c'est tout moche, mais cela à pour effet d'ignorer l'erreur de sélection tout en laissant excel faire cette sélection si c'est possible. cela laisse  le temps à gysmo_15 de mieux analyser le code pour supprimer les selects si possible!
 
 
NB: le plus étrange, c'est qu'en enregistrant une macro en live qui ne fait que sélectionner un onglet , le code généré en auto par excel provoque aussi l'erreur 9 sur mon xl2007/citrix
 
a+

Salut, dans le genre bonne pratique : l'usage du CodeName dans le code VBA voir http://www.developpez.net/forums/d [...] ost5196611