XL 2016 Ouverture fichier en vba stopper par le thisworkbook du fichier ouvert

[nicroq]

Bonjour à tous!!

un problème me bloque pour faire un copier coller d'un fichier à une autre à cause du fait qu'il y ait une macro dans le thisworkbook du fichier qui s'ouvre...

En effet la macro du fichier A ouvre un fichier B qui possède une macro dans thisworkbook. Du coup la macro du fichier A ne s'achève pas à cause du fichier B qui s'ouvre...

Avez vous une solution ?

et merci pour votre aide d'avance
Cordialement

 

[Hasco]

Bonjour,

Avec si peu d'éléments je ne vois qu'une chose, insérer un 'Application.EnableEvents = False' (stopper la gestion des évènements) avant l'instruction qui ouvre le fichier B et un 'Application.EnableEvents = True' après (rétablir la gestion des évènements)

cordialement

 

[Dudu2]

Bonjour,

Si tu veux que le classeur appelant garde la main après l'ouverture du classeur appelé (qui exécute sa propre macro à son ouverture) et exécute les instructions suivantes il faut que tu rendes asynchrone la macro du classeur appelé.

Dans le classeur appelé, au lieu de

Private Sub Workbook_Open()
    <Instructions>
End

Faire:

Private Sub Workbook_Open()
    Application.OnTime Now, "WorkbookOpen"
End

Et dans un Module séparé (en remplaçant les éventuels Me. par ThisWorkbook.)

Sub WorkbookOpen()
    <Instructions>
End

Edit: Attention si tu veux récupérer dans le classeur appelant des infos du classeur appelé, il sera peut-être (?) nécessaire de temporiser un peu du coté du classeur appelant pour laisser le temps au classeur appelé de s'ouvrir et faire ce qu'il a à faire à l'ouverture.
En principe le Set Workbook retourné à l'ouverture du classeur appelé devrait être OK mais en cas de problème tu peux par exemple boucler sur Application.Workbooks.Count avant / après et placer un petit Sleep dans la boucle. Ou encore jouer sur la présence d'un indicateur que la macro de l'appelé placerait quelque part dans le classeur.

Edit: A noter que si l'appel du classeur appelé est déclenché par un bouton ou une autre Shape des Contrôles de formulaire dans le classeur appelant, le classeur appelé peut connaître le nom de la Shape qui a déclenché la macro qui l'a appelé avec Application.Caller. Si c'est un Contrôle Active X, non !

 

[patricktoulon]

bonjour

je te suggère de t’intéresser a la différence de deux événement dont un qui n'est pas implémente dans le module thisworkbook


Sub "Auto_open()" ou "WorkBook_Open()" telle est la question 😉

 

[patricktoulon]

voici 2 fichiers wbk1.xlsm et ouvreur.xlsm
ouvre wbk1 tout seul tu a le message
ferme le
ouvre ouvreur et lance la sub ouvre pour ouvrir wbk1
magique non ?? 😉

 

[nicroq]

Merci pour tte vos réponse!

Application.EnableEvents = False' semble parfaitement fonctionner!

merci pour réactivité

bonne journée a tous

 

[patricktoulon]

Merci pour tte vos réponse!

Application.EnableEvents = False' semble parfaitement fonctionner!

merci pour réactivité

bonne journée a tous

oulah!!!!c'est pas une bonne idée !!! car tu sais pas selon le pc et ces capacités au moment de l'ouverture a quel moment il faut réactiver les events

non pas bien !!!!!! mais vraiment pas du tout 😉
tu n'a qu'une seule chose a faire et hyper simple
c'est de transférer le code qui dans le le workbook-open dans une sub Aut😵pen() dans un module standard
ca changera rien au comportement du classeur quand on l'ouvre tout seul
mais le code ne s’exécutera pas si le classeur est ouvert par vba d'un autre classeur
( simple, propre et net ) et on touche pas au param de l'app excel

voir et expérimenter avec les deux fichiers en exemple

 

[Dudu2]

@patricktoulon,

En effet la gestion des évènements c'est pas l'idéal mais si ça fonctionne dans son cas, pourquoi pas.

Tu aurais dû expliquer plus tôt en mots la différence entre le Workbook_Open() qui s'exécute quelque soit le mode d'ouverture du classeur et Auto_ Open qui s'exécute si le classeur est ouvert manuellement et ne s'exécute pas si le classeur est ouvert par une macro.

Maintenant si l'exécution de la séquence Workbook_Open() est nécessaire pour par exemple mettre à jour des dates ou autres "calculations", il faut passer par une exécution asynchrone.

Quoiqu'il en soit, 3 solutions pour 1 problème, c'est quand même pas si mal ! 😎

 

[patricktoulon]

re
haie!!haie!!

Maintenant si l'exécution de la séquence Workbook_Open() est nécessaire pour par exemple mettre à jour des dates ou autres "calculations", il faut passer par une exécution asynchrone.

Absolument pas
rien ne t’empêche mais alors rien du tout de lancer l’exécution de "sub Aut😵pen()" a partir du classeur qui ouvre au moment ou tu veux et pour ce que tu veux
comme ça c'est vraiment toi qui pilote le zingue( heu... les deux!! 😉 !)

allez un exemple comme ca vite fait a l'arrache
reprend le ouvreur et change la macro "ouvre" pour celle ci

Sub ouvre()
Set wbk1 = Workbooks.Open(ThisWorkbook.Path & "\wbk1.xlsm")
reponse = MsgBox(wbk1.Name & " est ouvert voulez vous lancer sa macro d'ouverture ", vbYesNo)
If reponse = vbYes Then
MaMacro = "'" & wbk1.Name & "'!Module1.Auto_Open"
Application.Run MaMacro 'Exécution de la macro
End If
End Sub

voila c'est toi le pilote ou pas 😉 😀

 

[Dudu2]

Tu veux dire à partir d'un Application.Run ("'" & <Nom Complet Classeur Appelé> & "'!Aut😵pen") ?
Certes, c'est également possible.

 

[patricktoulon]

revoir le post précédent
et j'appuie bien sur le fait que le pilote dans cette config c'est toi du début a la fin
pas avec une exécution non syncro ou tout autre blocage d'events et compagnie
c'est le B A B A pour la manip multi classeurs
tout autre méthode est certes parfois fonctionnel mais ajoutent du temps d’exécution et parfois plantent par ce que justement il est impossible de gérer un temps défini qui sur 10 pc sera différent
😉
comme ça tu gère absolument tout