|The script in the thread
COMScriptThread manages a thread with a scripting host in it. It also
supplies to the script in it one or two namespaces which give the
script ability to access the thread parameters (see also the Value
property) and thus communicate with the outer application (that
created the script) and the second namespace is optional (by default
exists - see AddCreator property). It is a Pack1Creator
object created together with the script in the same thread and
provides it with an easy way to create other COM objects as needed.
Through it the script has somewhat faster access to the other objects
in the library (ActiveX Pack1), their creation is much faster then
using the script's own CreateObject/new ActiveXObject methods and also
allows the script to create composite objects if needed.
The script life cycle is from the call to the Start
method to the call of the Stop
method (or object release if the Stop is not explicitly called). After
the call of the Start method the COMScriptThread initializes the
scripts and runs it. Depending on the wait parameter of the
Start method the COMScriptThread waits the script to complete or runs
it and returns immediately. After the linear execution of the script
it remains active and if it is designed for this the application may
execute some routines from it asynchronously - i.e. request their
execution in the thread. So, the application has two major choices on
how to organize its usage of the thread - do everything in one step or
initialize the script in the thread and request certain tasks to be
performed from time to time.
The script in the thread sees the namespaces mentioned
Context - the context dictionary/collection. It
is implemented as a VarDictionary
object. The script can read/write named or unnamed values in it, refer
to them by numeric index etc. By default it is configured to
keep values not objects (see VarDictionary.extractValues
property). This behavior prevents threading model issues that may
occur if the script or the application attempt to put inappropriate
objects there. So, the communication should be based only on values -
and not objects. For example you should not try to put an ADO
recordset object in this collection.
Creator - if available (default) it is a Pack1Creator object
created together with the script in the same thread. The script may
use it to create whatever COM objects it needs.
Applies to: COMScriptThread