Basic Architecture

The illustration below shows the interaction between an ActiveX Scripting host and an ActiveX scripting engine.

The following list annotates the steps involved in the handshake (the actual nesting of the calls has been omitted for clarity):

1. Create Project. The host will load a project/document as it sees fit. (This is not really a step particular to ActiveX Scripting but has been included here for completeness.)
2. Create the ActiveX Scripting Engine. The host calls CoCreateInstance() to create a new ActiveX Scripting engine, specifying a CLSID to identify the specific scripting engine to be used. The HTML browser, by way of example, will be given this class id through the PROGID= attribute on the HTML OBJECT tag.
3. Load the Script. If the script contents have been previously persisted, the host then calls the script engine's IPersist*::Load() method to feed it the script storage, stream, or property bag. Otherwise, IPersist*::InitNew() or IActiveScriptParse::InitNew() is used to create a null script. Hosts maintaining a script as text can use IActiveScriptParse::ParseScriptText() to feed the scripting engine the text of the script, after calling InitNew().
4. Add Items. For each top-level named entity imported into the scripting engine's namespace (such as pages and forms), the host calls IActiveScript::AddNamedItem() to create an entry in the engine's namespace. This step is not necessary if such items are already part of the persistent state of the script loaded in step 3. Sublevel named items (such as Controls on an HTML page) are not added via AddNamedItem(), but rather, are obtained indirectly from top-level items through ITypeInfo and IDispatch.
5. Run the Script. The host calls the IActiveScript::SetScriptState(STRIPTSTATE_CONNECTED). This call would likely perform any scripting engine construction work, including static bindings, hooking up to events (see below), and executing something similar to a scripted "main()" function.
6. Get Item Information. Each time the script engine needs to associate a symbol with a top-level item, it will call the IActiveScriptSite::GetItemInfo() method. This method returns information about the object corresponding to the name passed in.
7. Hookup Events. In the final phase before starting the actual script, the scripting engine will connect to the events of all of the relevant objects via IConnectionPoint and other methods.
8. Invoke Properties/Methods. As the script runs, references to methods and properties on named objects will be realized by the scripting engine through IDispatch::Invoke() or other standard OLE binding mechanisms.

The following terms are used to refer to entities in the above diagram:

Host	The application or program that owns the ActiveX Scripting engine. The host implements IActiveScriptSite and optionally IActiveScriptSiteWindow.
Scripting Engine	The OLE object that implements IActiveScript and optionally IActiveScriptParse.
Script	The data that makes up the "program" that the scripting engine runs. The script gets loaded into the scripting engine via IPersist* or IActiveScriptParse.
Scriptlet	A portion of a script that gets attached to an object via IActiveScriptParse. The aggregate collection of scriptlets is the script.
Script Language	The language (for example, VBScript) and the semantics thereof.
Named Item	COM object (OLE Automation support is preferable) that the host deems interesting to the script. Examples include the HTML Page and Browser in a Web Browser, and the Document and Dialogs in Microsoft Word.
Code Object	An instance created by the scripting engine that is associated with a named item, such as the module behind a Form in Visual Basic, or a C++ class associated with a named item. Preferably, this code object is an OLE COM object supporting OLE Automation so that the code object can be manipulated by the host or another nonscript entity.