Component architecture

The architecture of the component is simple. It consist of a namespaces/objects collection and script manipulation members - all combined in one object.

Typically collections are implemented in a separate objects, but because of the pusrpose of the collection here its members are combined with the script manipulation members in one object.

Namespaces collection holds interface (IDispatch) pointers to the objects that become global namespaces for the script when it runs. Namespaces are added with Add method of the ScriptManager2. Their names are passed to the script engine and the corresponding interface pointer is given to the script when the name is refered. You can add new namespaces at any time but removal can be done only if the script does not run - you can test this using locked property. When the property is true namespaces can not be removed and the script is at least in the running state. To remove/replace some of the namespaces you will need to call Stop method first and then remove some (or all) of the namespaces.

Windows Scripthing Host example:

// Create the component
var scph = new ActiveXObject("newObjects.Scphost.ScpMan2");
// Add scripting host WScript object as namespace to the ScriptManager2
// with name "world"
scph.Add("world",WScript);
// Load VBScript engine
scph.LoadEngine("VBSCRIPT");

// Define the VBScript code 
var str = "world.Echo \"Hello World!\"";
// Add the code
scph.AddText(str);
// Run the script - output must appear
scph.Run();
WScript.Echo("============");
// Clean up (not required in this example)
// Close script engine
scph.Close();
// Release the namespaces collection
scph.Clear();

To simplify the sample there is no error checking.

Script manipulation members are methods that change the script state - Run, Stop, Close, Connect , methods for code manipulation - AddText, AddEventHandler, LoadEngine and properties that give access to the state information and to the running script itself - locked, lastError, script. See the previous example for the simple usage of some of them.

Comments

One of the most interesting features provided by the Microsoft Active Scripting is ability to call script functions like a methods of the dispatch interface. This gives to the programmers ability to treat script as a transparent extension of the application. Many people think that these scripts are too slow, many programmers prefer to writhe everything in C++ but what is the truth? Yes the scripts are not fast as like a compiled language but the slowest phase of their life is initialization. Once initialized script needs just interpretation of the script text (note that some script engines do the run time compilation) - not initialization. Thus if the structure of the application does not require reload of the script it will be fast enough for non time-critical actions, user interface control, controling group of ActiveX components and many other tasks. Something more - when the conversation is about the usage of many ActiveX components and just calleng their members and setting/getting their properties - script is very good choice. Major part of the script engines (not only the engines provided by the Microsoft) support automation and at the other hand automation was designed for the scripts. Writting such controlling code in C++ sometimes requires too much writting and can lead to many errors (Take a look on the dispatch wrapers generated by the MFC wizzards). Scripts provide easy and flexible way to access ActiveX components - passed as namespaces or created at run time. Thus script can be the true choice for the demon that makes group of components to form an application without losing too much speed but gaining flexibility.

See the MFC example that uses script as like a metafile language. In this example script members are called on every repaint of the window. And as you can see it happens with acceptable speed. Of course this usage is only for example but it shows that avoiding reloads makes the scripts applicable in many areas. Combining this with ability to save development time and ability to make the applications flexible and programmable it is resonable to say that Active Scripts are the best choice for every application part where flexibility and development time are the most critical factors.