Ne pas activer macro Workbook_open d'un fichier ouvert depuis un autre avec CreateObj

Salut Currahee,

J'ai regardé, ça à l'air de ressembler à ce qu'ils ont écrit plus haut, mais j'ai pas creusé :o)

Sinon j'ai trouvé un truc :

Code:

---

Workbooks.Open Filename:=nom, ReadOnly:=True, Notify:=False, UpdateLinks:=0, CorruptLoad:=xlExtractData

---

en gras l'option qui ouvre le classeur en mode "Récupération de Données" dans le cas d'un fichier endomagé, une sorte de "démarrage sans échec" qui ne charge que la collection des Cells(i,j).value donc pas les données VBA donc pas le Workbook_Open... :king:

Bonjour,
Si j'ai bien compris le pb, le workbook.open ne doit pas s'exécuter si le fichier est ouvert pr la macro d'un autre fichier.
Donc,
dans tes macros Workbook.open, ajour le code pour vérifier si ledit fichier est ouvert. Si oui, termine la macro Workbook.open

Code:

---

1 2 3 4 5 6 7

For Each WB In Workbooks If WB.FullName = "fichierxx" Then GoTo suiteducode Exit For End If Next WB suiteducode

---

bonne soirée

Citation:

---

Envoyé par frolland46

Code:

---

1 2 3 4 5 6 7

For Each WB In Workbooks If WB.FullName = "fichierxx" Then GoTo suiteducode Exit For '<--- pas besoin End If Next WB suiteducode '<--- manque les ":" pour signaler que c'est un label, sinon il chechera une procédure

---

---

quoi qu'il arrive la suite du code sera exécutée, si il trouve le fichier ouvert il sort du for, si il le trouve pas il sort du for donc c'est pareil.

le code pour faire ce que tu décris c'est :

Code:

---

1 2 3 4 5 6 7 8

For Each WB In Workbooks If WB.FullName = "fichierxx" Then GoTo suiteducode Exit For End If Next WB exit sub '(ou function au choix) suiteducode:

---

perso j'aime pas trop les GoTo...

Code:

---

1 2 3 4

For Each WB In Workbooks If WB.FullName = "fichierxx" Then Exit Sub'(ou Function au choix) Next WB ...'le code normal du Workbook

---

de plus:

Citation:

---

Envoyé par LentilleLocale

Merci Didier mais les fichiers liés ne sont pas de moi
Je ne peux donc remplacer les Workbook_open par des Auto_open n'en étant pas maître
...

---

merci pour l'idée

Citation:

---

Envoyé par LentilleLocale

... en utilisant le modèle ADO

La commande que j'utilise CreateObject("Excel.Application").Workbooks.Open ...

---

je suis entrain de modifier mon projet pour passer par ADO car il me semble que c'est beaucoup plus rapide que CreatObject, et en plus tu ouvres quand même le classeur puisque tu utilises la fonction Open, même si ce n'est pas visible lors de l'execution. Et en plus c'est pas si compliqué que ça par ADO... moi j'y connais absolument rien en bases de données et j'ai compris comment ça marche (grâce au lien de Ouskel). A toi de voire.


+
Rag

Citation:

---

Envoyé par LentilleLocale

1) Le code 1 avec CreateObject (Temps de traitement 1 minute 15 pour 4 fichiers lus) : le code des fichiers lus est exécuté (workbook_open et workbook_before close)


2) Le code 2 avec Set Wk ( (Temps de traitement 5 minutes 12 pour 4 fichiers lus) : le code des fichiers lus n' est pas exécuté (ce que je souhaite)
Cependant le traitement est 5 fois plus long que par CreateObject



3) et le code contenu dans chaque Fichier appelé dans ThisWorbook et que je ne veux pas voir s'exécuter lors de l'appel depuis le fichier de synthèse (hors, à mon gd désespoir, le userform se lance dans le 1er code à l'ouverture et, lors de la fermeture du fichier, on tombe en erreur car je n'ai pas Hyperion installé chez moi contrairement au bureau (ESSEXCLN.xll Erreur 53)


En résumé :
1) comment optimiser le temps d'exécution du 2ème code (5 fois plus lent que le 1er code mais n'exécute pas, comme souahité, les macros des fichiers appelés) --> Peut-être en forçant l'exécution dans une 2ème instance d'Excel ?
2) comment empêcher l'exécution des macros à l'ouverture et à la fermeture des fichiers appelés pour le 1er code (qui est 5 fois plus rapide que le 1er)

Avec le code 3, ouvrant une 2ème instance excel, j'obtiens une performance identique au 1er code mais les macro se lancent encore malgré le xlApp.EnableEvents = False
Mais pourquoi donc ????

---

Salut,
Je pense que si tu utilises 2 instances tu dois mettre un EnableEvents = False
dans les deux donc tu dois ajouter
application.EnableEvents = False avant de créer ta 2ème instance.

Pour ce qui est de la lenteur ajoute Application.ScreenUpdating = False et tes codes devraient mettre le même temps.

HS... Désolé pour mon incohérence habituelle...

Je ne cherche pas à comparer avec ADO mais juste à déboguer son code.

Pour moi
Set xlApp = New Excel.Application et Set XlApp = CreateObject("Excel.Application")
c'est pareil sauf que pour le premier il faut référencer Excel.

La différence avec une nouvelle instance c'est donc que celle-ci n'est pas visible comme quelqu'un le faisait remarquer, donc à mon avis ca doit accélerer le code 2.
http://xcell05.free.fr/pages/prog/accvba.htm

http://www.developpez.net/forums/m3635999-9/

C'est ça les long post ouskel'n'or , on ne retient pas tout ;-))

Et si, dans le code suivant,

Code:

---

1 2 3 4

Dim XlApp as Object Set XlApp = CreateObject("Excel.Application") XlApp.EnableEvents = False ' devrait normalement empêcher le lancement de la macro du fichier appelé With XlApp.Workbooks.Open(RepertoireSource & Fichier)

---

c'était simplement une question de paramètre non reconnu ? (False)
As-tu testé avec

Code:

---

XlApp.EnableEvents = 0

---

Sait-on jamais (?!?) Je testerais.
Mon idée ? Quand on utilise une instance de Word, les paramètres de Word ne sont pas reconnus et doivent être remplacés par leurs valeurs (tout au moins en déclarant WdApp as Object). Je sais que False est reconnu partout mais sait-on jamais...
A tout hasard, vraiment ! ;) Et à vrai dire je n'y crois pas :(