Un objet d'Automation ne se 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 avez deviné, vous soyez à court de ressources. On
peut détecter ces instances cachées de par le Task Manager ou le Task List.
Essayez ce code, par exemple:
Dim objXL As Object
Set objXL = CreateObject("Excel.Application")
objXL.Visible = True
Set objXL = Nothing
Le point crucial est le suivant: 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")
objXL.Quit
Set objXL = Nothing
Si la propriété UserControl de
l'objet est False, et que votre variable-objet perd, sort, de son étendue (scope), l'application terminera. C'est cette propriété qui autrement
laisse l'objet ouvert.
Information additionnelle
Voisin quelques articles de MSDN
qui vous apporteront un supplément d'information sur la durée de vie des objets pilotés par Automation:
Managing Object Lifetimes in OLE Automation
(by Douglas Hodges)
Q147816: ACC: Using Microsoft Access as an Automation Server
Extraits:
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:
- The user creates an instance of Microsoft Access,
which sets the UserControl
property to True.
- 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.
- The user restores Microsoft Access
using the Windows taskbar (or Task List in Windows NT).
- 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:
- 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.
- 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.