Bonjour,
 
J'ai écrit un programme en VBA qui s'est mis à fonctionner différemment depuis quelques jours :
 
Avant l'instruction Workbooks.Open xxxx.xls activait également le classeur xxxx.
Maintenant  Après l'instruction Workbooks.Open xxxx.xls c'est toujours le classeur contenant le code vba qui reste actif
et pour modifier le classeur xxxx j'ai dû coder :
 With workbooks(workbooks.count)
   .worksheets....
etc
End with
 
Entre Avant et Maintenant j'ai installé Office 2013 qui posait des pb, et je suis revenu à Office 2010 avec un fonctionnement différent de l'instruction Workbooks.Open. Pour info les modèles ".xlt" ouverts par Workbooks.Open yyyy.xlt deviennent bien les classeurs actifs4
Merci de vos lumières

Bonjour,
 
Utiliser un objet actif (tel que Activeworkbook) est toujours une prise de risque inutile !
 
Il est préférable d'écrire :

puis d'utiliser wbk.  

 
@patrice33740
Merci de la réponse, ce que j'avais commencé à faire...  Pour la petite histoire le programme fait 15000 lignes avec une base Access, une vingtaine de userforms et manipule de nombreux classeurs Excel) d'où le boulot..
 
Néanmoins ce qui me turlupine est que ce programme fonctionnait bien sous Office 2010, et qu'il ne fonctionne plus sous son ancienne version depuis que je suis revenu à Office 2010 après avoir installé Office 2013. A moins qu'une mise à jour de Windows 10 soit venue semer la zizanie.

Je reviens à la charge pour un problème connexe :
 
J'ai un Userform dont le code ouvre un classeur Excel puis appelle une procédure, stockée dans un module, qui édite le classeur Excel,.. et lorsque la procédure ferme le classeur Excel par la commande Workbooks(xxx).close savechanges := false, cette commande provoque également le Unload du userform.
Et qui plus est :
 
1 - Ce problème es apparu avec Office 2013 et n'apparait pas lorsque le même programme est lancé sous Office 2010.
2 - je ne sais pas pourquoi mais ce problème n'apparait que pour les classeurs à éditer créés récemment (depuis le 28/09 pour être précis) c'est à dire sous Office 2013.
 
Pour info le programme a été réenregistré sous Office 2013. Et j'ai fait toutes les modifs pour ne plus utiliser activeworkbook.
 
si par hasard une idée ? Merci

Bonjour,
 
C'est curieux!
Mais si tu fais comme je t'ai dit : set wbk = ...
Pour le fermer c'est :
wbk.Close False

bonjour,
 
J'ai essayé scrupuleusement ta solution; hélas c'est la même chose :
Dans certains Userforms, (toujours les mêmes) l'instruction de fermeture d'un classeur provoque le déchargement du formulaire qui la contient (sa fenêtre disparait de l'écran). le reste du code du formulaire s'exécute correctement tant qu'il n'est pas fait utilisation d'une variable locale.
 
Je confirme que ce comportement :
- se produit avec Office 2013  
- ne se produit pas avec Office 2010
 
- se produit sur des formulaires dont la taille est très importante et qui se trouvent exécutés selon un processus d'enchainement de formulaires plus ou moins alambiqué (hide, unload, load, show). Néanmoins le contexte du bug est toujours le même : c'est le formulaire actif qui plante dès la première instruction utilisant une variable locale qui suit l'instruction wbk.close.  
 
Pour info l'exécution de cette application (VBA Excel + base Access) est 20% plus longue sous 2013 que sous 2010, merci qui ?
 
En tous les cas c'est frustrant de ne pas connaitre l'origine exacte du pb, vraisemblablement mauvaise programmation, ce que je préfèrerais, plutôt qu'un bug vba Excel

Difficile de répondre sans la totalité des différents codes.
 
C'est peut-être un problème que j'ai déjà eu en employant Application.ScreenUpdating = False avec excel 2016 (et 2013).
Le problème est lié à la nouvelle interface SDI apparue avec Excel 2013 : L'onglet affiché n'est pas l'onglet actif !!!
Voici la solution que j'avais adopté (ajouter ForEachWinDoEvents après le Application.ScreenUpdating = True)
Explication : le DoEvents n'agit que sur la fenêtre active, depuis Excel 2013, il faut en faire autant qu'il y a de fenêtres ouvertes dans l'application.
 

Merci de cette précision, et d'une solution de contournement que je vais tester. j'avais bien lu quelque part que la nouvelle interface SDI apparue avec Excel 2013 pouvait poser pb..... mais pas la parade.

Bonjour,
 
Effectivement cette programmation a corrigé la plus grande partie de mes problèmes.
L'autre partie dont je n'avais pas parlée était que le logiciel se comportait différemment selon que les classeurs Excel étaient sur mon PC ou sur un "serveur" - ou plutôt sur le disque dur de ma Freebox -  
J'avais déjà contourné le pb en exécutant la fermeture des classeurs en fin de procédure et non pas le plus tôt possible.
 
Il n'en reste pas moins que VBA n'est pas fait pour des presque-néophytes comme moi, lequel pour satisfaire bénévolement les besoins informatiques initiaux d'une toute petite PME (qui est passée de 5 à 40 salariés en 15 ans !) a commencé à coder quelques macros et formulaires sous Excel pour un seul PC pour arriver à un monstre de 15000 lignes, avec une base Access et des centaines de fichiers Excel, utilisé par 5 ou 6 personnes et donnant néanmoins entière satisfaction jusqu'à ce passage sous Office 2013.
Grand merci pour tes suggestions efficaces.
Ed

Bonjour svp aidez moi a corriger ce code
 
Sub ajouter_eleve()
'
'ajouter_eleve Macro
'
 
'
   Sheets("formulaire" ).Range("A2:E2" ).Select
   
   Selection.Copy
   Sheets("bdd" ).Select
   Range("A1" ).End(xlDown).Offset(1, 0).Select
   Selection.PasteSpecial Paste:=xlPasteValues, Operation:=xlNone, SkipBlanks:=False, Transpose:=False
   Sheets("form" ).Select
   Range("B4" ).Select
   Application.CutCopyMode = False
   Selection.ClearContents
   Range("D4" ).Select
   Selection.ClearContents
   Range("B7" ).Select
   Selection.ClearContents
   Range("B10" ).Select
   Selection.ClearContents
   Range("B13" ).Select
   Selection.ClearContents
   Range("D13" ).Select
End Sub

Par exemple :