---Soumis par Dev Ashish---

Un objet d'Automation ne ferme pas automatiquement.

    Lorsque vous utilisez Automation pour créer de nouvelles instances de Word ou de Excel, assigner l'objet à Nothing ne ferme pas l'instance automatiquement. En plus, à moins que vous n'ayez spécifiquement assigné la propriété visible à Vrai, plusieurs instances d'un tel code vont continuer à créer de nouveaux objets invisibles jusqu'à ce que, vous l'avez deviné, vous vous retrouviez à court de ressources. On peut détecter ces instances cachée de par le Task Manager ou le Task List.

Essayez ce code, par exemple:

    Dim objXL As Object
    
    Set objXL = CreateObject("Excel.Application")

    'quelques lignes impliquant l'objet créé par Automation 

    objXL.Visible = True
    
    Set objXL = Nothing

Pour fermer ces instances, vous devez utiliser la méthode  Quit de l'application.  Donc, votre code devrait ressembler à:

    Dim objXL As Object
    
    Set objXL = CreateObject("Excel.Application")

    'toujours votre code 
    
    objXL.Quit
    Set objXL = Nothing

--- De Michael Kaplan---

    Si la propriété  UserControl de l'objet est False, et que votre variable-objet perd sort de sa portée (scope), l'application termiera. C'est cette propriété qui  autrement laisse l'objet ouvert.

Information additionnelle

   Voisin quelques articles de MSDN qui vous apporteront de l'information additionnelle au sujet de la durée de vies des objets créés par automation:

    Managing Object Lifetimes in OLE Automation (by Douglas Hodges)

    Q147816: ACC: Using Microsoft Access as an Automation Server

De l'article ci-haut mentionné:

UserControl Property

The UserControl property is always read-only; therefore, you cannot set it using Automation. However, the UserControl property can change automatically if a user intervenes while your Automation code is idle. For example, the UserControl property is changed to False when the following events occur:

 

1. The user creates an instance of Microsoft Access, which sets the UserControl property to True.
2. You run Automation code in the controller application, which uses the GetObject() function to activate the previously opened instance of Microsoft Access. The object variable that you use for the instance is a Public or module-level variable.
3. The user restores Microsoft Access using the Windows taskbar (or Task List in Windows NT).
4. The user tries to close Microsoft Access by clicking the Close box. The instance does not close as expected because the Automation controller has a Public or module-level object variable referring to that instance of Microsoft Access. Instead, the instance is minimized, which sets the UserControl and Visible properties to False.

Similarly, the UserControl property is changed to True if the following events occur:

1. You create a new instance of Microsoft Access using Automation. The UserControl property is False. The Visible property is also False; therefore, the instance is minimized.
2. The user restores the instance using the Windows taskbar (or Task List in Windows NT). Or, you call the ShowWindow() API function in Visual Basic to restore the instance using code. In both cases, the UserControl and Visible properties are changed to True. 

If the UserControl property is True, it can affect your ability to control the on-screen behavior of Microsoft Access. Specifically, you should watch out for the following limitations:

• You may receive an error message in your Automation code when you try to set the Visible property to True; the Visible property is read-only when the UserControl property is True.
• You cannot trap or suppress an error message generated by Microsoft Access as the OLE Server application. If you execute a bad command, such as trying to open a form that does not exist in the current database, an error message is displayed.
• An instance of Microsoft Access does not close automatically when the object variable referring to the instance (objAccess) is set to Nothing or it loses scope.