Projet VBA reste ouvert

Bonjour,

J'ai un projet avec un classeur et lorsque je ferme le classeur le prjet VBA reste dans l'autre classeur ouvert en //. Mais l'apparence est sous forme de icone bleu pour les feuilles.

Quand je rouvre mon classeur celui ne s'execute pas normalement.

Pouvez vous m'aider svp pour comprendre pourquoi mon projet reste actif ?

Une réponse permettra de répondre à la question BUGS 2 classeurs ouverts

merci

jasserin

Bonjour,

Tu n'es plus tout à fait "un bleu" sur ce forum.

Si tu espères une réponse, l'usage veut à chaque fois que tu ouvres un nouveau fil de joindre le classeur correspondant.

Ainsi les intervenants ne seront-ils pas obligés de se livrer à un jeu de piste pour comprendre de quoi tu parles.

De plus cela assure qu'à chaque fois ils ont la dernière version du code disponible.

Les intervenants sont rarement les même d'une fil à l'autre et tu es le seul à être capable de faire le joint entre tes différents sujets ouvert et ton projet.

Exceptionnellement j'ai fait cet effort de recherche pour voir plus ou moins comment est ficelé ton projet.

Malheureusement ce que j'ai vu n'est guère conventionnel et il me semble que tu devras d'abord faire un gros effort de standardisation si tu veux continuer de travailler dessus.

Mais la consultation de l'historique des fils est peu pratique et je n'ai pas le courage de tout dépiauter pour essayer de comprendre. J'ai toujours l'impression qu'il en manque un bout.

Donc si tu veux qu'on te consacre un peu de notre temps, tu nous aides un peu à ne pas en perdre (en joignant ton fichier)

Tu peux supprimer la quasi totalité des données sur les feuille, mais le code VBA complet est indispensable.

A+

Bonjour,

Ok désolé pour l'oubli. Je joins donc le fichier en question . Si j'ai bien compris ma façon de programmer n'est pas très bonne, peux tu me dire pourquoi que je comprenne les erreurs ?

merci beaucoup,

jasserin

Bonjour,

Probablement une erreur dans l'utilisation de EnableEvents

EnableEvents = False doit être utilisé juste avant la ligne entrainant l'évènement à inhiber

et il faut remettre à True sur la ligne juste après. ce qui n'interdit pas de mettre une gestion d'Erreur en plus entre les 2 (au cas ou....)

EnableEvents = False 
On error Goto GESTERREVENTS
Sheets(i).Activate '(Produit une erreur si Sheets(i) n'existe pas)
EnableEvents = True
'...
'Longue suite d'instruction
ExitSub
GESTERREVENTS:
EnableEvents = True
Resume next 'éventuellement
End Sub

est une bonne construction.

Pour la question concernant 2 classeurs, comme il n'en est est pas question dans ton fichier joint... c'est plus compliqué !

Ma façon de programmer n'est pas très bonne, peux tu me dire pourquoi que je comprenne les erreurs ?

Hum... Si t'insiste ! Je vais essayer de répondre à cette question en essayant de rester constructif.

Les principaux défauts (dans l'ordre d'importance)

1- Les variables doivent être déclarées dans chaque Sub ou Function et non en tête d'un module. (même s'il peut y avoir des exceptions)

2- Utilisation d'index pour les différentes feuilles abusive (dans ce contexte). Il faut utiliser les noms de feuilles ou -mieux- les CodeNames ou des instances de feuilles.

3- Il n'y a pas lieu de modifier les déclarations des Sub prédéfinies. Bien que ce soit autorisé. (laisser Target et pas "sel")

ActiveSheet.index à proscrire dans Workbook_SheetChange (C'est sh qui a déclanché la procédure : utilise les variables fournies)

Set d = a (ou b ou c...) C'est une histoire de fou ! Ya que toi qui peut comprendre une histoire comme ça.

L'usage veut qu'en VBA on utilise des noms de variables, Sub ou objets, courts (8 car maxi) mais suffisament "parlant"

WsS ou WsSource, WsC ou WsCible, iLR ou iLastRow, iLC ou iLastCol sont mieux que a,b,c,d ou dernière ligne ou dernierecolonne...

Personnellement je ne m'autorise des noms de variables à un seul caractère que pour des compteurs de boucle. (For i = 1 to 50...)

4- GoTo à bannir (sauf dans la gestions des erreurs sur le modèle ci-dessus)

5- Quatre écrans à défiler pour la gestion des accès et mots de passe : il y a surement un problème de conception ! (Notamment dans la gestion des protections)

Bon. Euh... On a tous commencé comme toi... J'ai bien conscience que je risque de te paraître un peu démoralisant.

Mais chaque langage à ses particularités, donc j'ai juste essayé de pointer les usages les plus répandus en VBA.

Après il y les exceptions quand on maitrise bien le truc on arrive à faire quelques entorses, mais quand les exceptions deviennent la règle... c'est le bazar !

Cordialement

Bonsoir,

Merci pour la réponse.

1- J'ai regardé dans mon programme et l'instruction enable est mis à false et ensuite mis à true donc je crois que cela doit être bon.

1- projet VBA qui reste ouvert : J'ai regardé sur le net et au lieu de activeworkbook.close, j'ai remplacé par thisworkbook.close et cela marche bien. le projet vba se ferme bien, même avec un autre classeur ouvert en //.

2- merci beaucoup pour les conseils d'écriture, je vais tenter de m'améliorer. Juste une question pour la déclaration des variables, je pensais qu'il fallait déclarer les variables en début avant le sub pour qu'elles aient une portée dans les autres modules ? mais si j'ai bien compris je pourrais mettre dans mon sub une variable sous la forme "public nom1" et cette variable sera reconnue par les autres modules ?

3- pour les déclaration des variables a, b, c .. ok je note.

encore merci, je vais mettre résolu pour mes deux dernières questions

à bientôt,

jasserin

Bonjour,

J'ai bien précisé qu'il peut y avoir des exceptions, mais ces exceptions ne doivent pas devenir une habitude.

Les variables déclarées Public en tête d'un module sont disponibles pour toutes les macros de tous les modules de tous les classeurs ouverts ce qui devrait être extrèmement rare.

On n'utilise jamais Public à l'intérieur d'une Sub.

Depuis 30 ans que je fume le VBA dans des conditions multiples, je n'avais encore jamais éprouvé la nécessite de variables Public... Ce qui ne signifie pas que ça n'arrivera pas un jour ! Mébon... Au stade ou tu en es de ton projet, ça m'étonnerait bien que tu saches déjà que tu aura la nécessité de telles variables pour d'autres projets.

Les variables déclarées par Dim en tête de module sont disponible pour tous les modules de ton classeur, ce qui devrait être exceptionnel. La plupart doivent être déclarées à l'intérieur de chaque Sub.

Déclarer une variable par Dim en tête de module doit correspondre à une nécessité (et non pas parce que tu ne sais pas faire autrement) En général, dans les classeurs ou elles sont indispensable de telles variables se comptent sur les doigts d'une seule main...

Tous les ActiveQuelqueChose devrait être bannis de même que les Select et autre Selection. qui conduisent à des incertitudes, imprécisions et autres quiproquo.

A+