[XL-2007] Lors de la fermeture d'Excel le processus reste actif [Résolu]

[courriervirtuel]

Bonjour à tous,

J'ai écrit un programme en VBA sous Access (2007) pour ouvrir et fermer des document en Excel (2007), je constate que quand je ferme le fichier en le sauvegardant soir avec l'instruction :

Code :

1
2
xlBook.Save
xlApp.Quit

ou bien avec l'instruction :

Code :

1
2
xlBook.Close True
xlApp.Quit

alors il enregistre bien, se ferme MAIS il reste toujours un processus Excel sur le gestionnaire de tâche.

En revanche, lorsque je ferme le fichier en Excel (2007) sans l'enregistrer avec l'instruction :

Code :

1
2
xlBook.Saved = True
xlApp.Quit

alors il n'y a pas de processus "résiduel".

Comment faire pour avoir la même chose au niveau de la fermeture avec enregistrement (pour qu'il n'y ait plus de processus résiduel).

Merci d'avance !

[Daniel.C]

Bonjour,

Qu'est-ce qui se passe si tu mets :

Code :

1
2
3
xlBook.Save
xlBook.Saved = True
xlApp.Quit

[courriervirtuel]

J'ai déjà essayé.
Il me mets la même chose que si je n'avais pas mis la deuxième des 3 lignes !

[Ormonth]

Bonjour,

vérification de base :

si tu mets un point d'arrêt avant ton code final et que tu regardes le gestionnaire, tu as combien d'instances Excel ouvertes ?

cordialement,

Didier

[courriervirtuel]

Dans les deux cas : fermeture avec enregistrement ou sans enregistrer,
il y a un processus Excel créé
et dans le cas de "avec enregistrement", il n'est jamais "tué" :

Code :

1
2
3
4
5
xlBook.Save
xlApp.Quit
Set xlSheet = Nothing
Set xlBook = Nothing
Set xlApp = Nothing

dans le cas des sans enregistrement, il est "tué" :

Code :

1
2
3
4
5
xlBook.Saved = True
xlApp.Quit
Set xlSheet = Nothing
Set xlBook = Nothing
Set xlApp = Nothing

!!

[Daniel.C]

Peut-être, ajoute un :

Code :

xlApp.DoEvents

avant

Code :

xlApp.Quit

pour lui laisser le temps d'enregistrer.

[courriervirtuel]

Je n'ai pas la propriété DoEvents sur xlApp !

J'avais essayé une avant

Code :

 xlApp.Workbooks.Close

...

Sinon, au départ, j'ai fait ça

Code :

1
2
3
4
5
6
7
8
 Dim xlApp As Excel.Application
    Dim xlSheet As Excel.Worksheet
    Dim xlBook As Excel.Workbook
 
    'J'initialise mes variables
    Set xlApp = CreateObject("Excel.Application")
    Set xlBook = xlApp.Workbooks.Open("D:\projet.xlsm")
    Set xlSheet = xlBook.Worksheets("root")

[Daniel.C]

Est-ce que tu peux créer une macro dans Excel avec la fonction :

Code :

DoEvents

comme ligne de code. Tu appellerais cette macro avant le Quit.

[courriervirtuel]

J'ai fait une fonction avec cette instruction et je l'ai appelé juste avant le quit, mais ça ne marche pas (je sais pas comment appeler une macro pendant mon code mais ça doit être la même chose)

Un élément qui est intéressant, c'est que si j'ouvre le fichier Excel (de manière classique en double cliquant dessus et en le refermant), le processus est "tué"
Par contre, purement par programme programme, il me créé beaucoup de processus Excel !!

[Daniel.C]

A tout hasard, avant le "Quit" :

Code :

1
2
3
Set xlSheet = Nothing
Set xlBook = Nothing
Set xlApp = Nothing

[courriervirtuel]

Ça aurait pu ! mais non !
Si je mets avant, ça bug à l'instruction quit vu que l'objet n'existe plus,
Si je zappe le quit, ça revient au même !!

N'y aurait-il pas un moyen de supprimer les processus Excel par programme ?!

Merci encore !

[Daniel.C]

N'y aurait-il pas un moyen de supprimer les processus Excel par programme ?!

Il me semble que c'est possible, mais c'est trois crans au-dessus de mon niveau
Si c'est de créer de multiples instances d'Excel, pourquoi vouloir la fermer et pourquoi ne pas utiliser "GetObject" pour se réapproprier l'instance ouverte ?

[courriervirtuel]

Je pourrais, mais je ne sais pas quel objet je récupère, il se peut que ça soit un fichier excel ouvert autrement...

[Ormonth]

Envoyé par Daniel.C

Si c'est de créer de multiples instances d'Excel, pourquoi vouloir la fermer

Non, Il vaut mieux toujours faire le ménage dans ce genre de choses, sauf volonté contraire délibérée en pleine connaissance et maîtrise de choses ?

@ courriervirtuel

Pour ton instance Excel, tu travailles en instance visible ou cachée ?

Sinon, il y a de très forte chance qu'il y ait une référence à un objet qui n'est pas supprimée et ton appli reste en l'air...

voir si tu as bien libéré toutes tes variables objet et si tu ne crées pas de références implicites ( cqvd : donc il faut écrire ton code de façon explicite)

cordialement,

Didier

[courriervirtuel]

Merci pour la réponse,

Je travail en instance cachée...
J'ai libéré tous les objets en relation avec l'ouverture de mon fichier Excel.

En plus, ça marche avec

Code :

xlBool.Saved = True

mais pas avec

Code :

xlBool.Save

et pas non plus avec

Code :

xlBool.Close True

qui sont les deux possible pour quitter avec enregistrement !

J'y comprends rien !

[Daniel.C]

Non, Il vaut mieux toujours faire le ménage dans ce genre de choses, sauf volonté contraire délibérée en pleine connaissance et maîtrise de choses ?

Oui , bien sûr, mais à défaut ?

[Ormonth]

Envoyé par Daniel.C

Oui , bien sûr, mais à défaut ?

à défaut, il faut chercher pourquoi, sinon ça te retombera dessus à un moment donné

Envoyé par courriervirtuel

J'y comprends rien !

Bon, j'ai déjà fait à partir d'Excel, Powerpoint ou Word et pas eu de souci, je pense qu'il faut que tu passes en méthode empirique, tu fait un exemple minimaliste avec juste ce qu'il faut (Visible ou non = pas de souci, c'est simplement que si tu as une instance Excel visible à côté, on peut se mélanger dans les pointages), et tu testes, si pas de souci, c'est qu'il n'y a pas de phénomène, mais que c'est dans le reste de ton code que tu invoques un truc qui reste en suspend...

Le processus sinon disparaît au déchargement de la variable objet (pointage).

Code :

Set ApExc = Nothing

Voici un code exemple OK (sous Word, mais bon)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Option Explicit
Public ApExc As New Excel.Application
Public wkbMonBook As Workbook
 
Sub Demarreur()
Dim gvStrChemS0 As String
Dim gvStrChemS1 As String
 
gvStrChemS0 = "D:\"
gvStrChemS1 = "+ Codes Postaux DGGGGGGGGGGG.xlsx"
Set wkbMonBook = ApExc.Workbooks.Open(gvStrChemS0 & gvStrChemS1)
ApExc.Visible = True 'False ne change pas la donne
End Sub
 
Sub Liquidateur()
 
wkbMonBook.Close savechanges:=True  'OK pour False aussi
Set wkbMonBook = Nothing
ApExc.Quit
Set ApExc = Nothing
End Sub

à partir d'un truc du genre qui te montre que ce n'est pas ce niveau le fautif, tu rajoutes ce que tu soupçonnes en premier...etc..


cordialement,

Didier

[courriervirtuel]

En y allant vraiment pas à pas, j'ai remarqué que dès que je rajoute une instruction qui modifie une cellule, le processus n'est pas "tué", même si l'instruction de modification est de type :

Code :

xlSheet.Cells(1, 1) = 1

!!

En résumé, sans aucune modification, si je ferme avec enregistrement (pas d'intérêt, mais bon), le processus est "tué",
Si, j'utilise une instruction telle que celle que j'ai mise en haut, le processus n'est pas "tué" !!

[Daniel.C]

@Ormonth :

à défaut, il faut chercher pourquoi, sinon ça te retombera dessus à un moment donné

Parfois, c'est un bug ou c'est "by design" et il faut chercher un contournement.

[Ormonth]

Envoyé par Daniel.C

@Ormonth :
Parfois, c'est un bug

Oui, mais sur des pratiques courantes, ils sont souvent référencés (utilité des forums ) même si pas toujours faciles à retrouver.

Sinon, on peut monter un échelon et publier 'un nouveau bug"...

Je n'ai pas l'impression qu'on soit dans ce cas, de toutes façons, il faut avant tout en identifier la cause.

Si identifié, le contournement est OK, sinon c'est reculer pour mieux sauter..

cordialement,

Didier