The 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 above as:

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. 

Examples:

Remarks:

Applies to: COMScriptThread object