Question Attente de fin d'exécution EXCEL

gregmurf écrit:

Comment fais-je pour vérifier cela ?

Bonne question
Je regarde comment différencier/retrouver le ClsID
gregmurf écrit:

Et qu'entends-tu par contexte d'appel ?

Session utilisateur vs tâche planifiée avec un compte de service par exemple.

gregmurf écrit:

J'ai une autre question: est-ce que le fait de ne lancer qu'une seule fois Excel, puis lancer une à une les macros ne serait pas mieux que d'ouvrir Excel, lancer la macro, le fermer, le réouvrir, etc... ?

C'est fort probable ,mais je n'ai pas plus d'arguments que ça.Faut tester

Pour retrouver le type de l'objet COM :
[code:1]
$workbook.pstypenames
#System.__ComObject#{000208da-0000-0000-c000-000000000046}
#System.__ComObject
#System.MarshalByRefObject
#System.Object
[/code:1]

gregmurf écrit:

Mais... toujours mon petit processus excel.

COM garde un compteur de références des objets créés, Il faut donc fermer/supprimer chaque objet COM que tu crées une fois que tu ne l'utilises plus. Sinon la référence reste active et 'empêche' la libération de l'objet COM.
Un exemple :
[code:1]
$excel = new-object -com Excel.Application
$classeurSource=\"$PWD\Test.xls\"
$MonClasseur = $excel.Workbooks.Open($classeurSource)
#Les deux appels suivant provoquent une erreur
$MonClasseur.Worksheets[1]
$MonClasseur.Worksheets(1)
#Accéde a la première feuille XL
$MonClasseur.Worksheets.Item(1)
$Excel.Quit()
#Force la libération des ressources
$null=[System.Runtime.InteropServices.Marshal::ReleaseComObject($MonClasseur)]
$null=[System.Runtime.InteropServices.Marshal]::ReleaseComObject($excel)
[System.GC]::Collect()
[/code:1]
On peut aussi affecter $null aux objets qui ne sont plus utilisés (sauf l'objet primaire), mais c'est parfois insuffisant.