Scripting Chat
The other day I was playing around with the Microsoft Script Control and comparing it to use of the native Active Scripting interfaces. It was interesting that the design of the Script Control interface was quite similar to the native interfaces — both provide a flat model of a single interface (versus a hierarchy of interfaces) and a simple model for setting up an engine, adding scripts, and executing them. However, the AddCode() method of the Microsoft Script Control illustrated how a host manages scripts with the underlying engines.
The documentation for the Script Control's AddCode() method says the following:
Adds specified code to a module.
Actually, this is a little vague. Although the Script Control has a notion of modules, the arguably most important module is the global module which is the default. Many developers working with the Script Control may never find a need to create specific modules other than the global module. This is particularly true if they don't work with Visual Basic and implicitly understand the concept of a module as the Script Control defines it:
A Module object is the ScriptControl member in which all procedure, type, and data declarations are made.
Basically, the module is a container of stuff, which in this case is code. Not really a class in the sense of what a C++ or C# (or VB.NET) developer would understand. Other languages such as Ada have a notion of packages, which are similar. Probably the closest concept to the module in the Script Control is a namespace in C++ or C#. But I digress.
What really jumps out at a developer new to the Script Control is that there is a means to add new script to the engine but no obvious means to remove it. The AddCode() documentation says nothing about the side effects of adding code to the engine, such as what happens if the script, or parts of it, already exist. The only way to find out is to, well, play around with the control.
I fired up trusty Notepad and wrote a small Jscript program that interacted with the script. The code looked like this:
var sc = new ActiveXObject("ScriptControl");
sc.Language = "JScript";
Pretty much self-explanatory. Create the script control and tell it I want to use the JScript language (actually, the JScript engine). Next, I added some code to the engine.
sc.AddCode( "function test(x,y) { return x + y; };" );
Finally, to run the code I added, I'd do this:
WScript.Echo( sc.Run("test",1,2) );
Which results in the value of "3" in a message box. OK, so it's not that complicated a script, but you get the idea of how straightforward the Script Control is.
But what happens if I need to change the definition of the test function?
Actually, the Script Control documentation has this rather cryptic comment:
AddCode may be called multiple times.
Most of the time, a developer would call AddCode() each time additional script needed to be added to the control. What's interesting is if you add script to the control which conflicts either partially or completely with script added previously. You might expect an error message. Actually, it works just fine. Thank goodness it does or Active Scripting wouldn't be as useful.
Looking at my example above, let's re-write the test function and re-add it:
sc.AddCode( "function test(x,y) { return x * y; };" );
I've changed the addition of x and y to a multiplication. Re-running the script results in a "2" being displayed. The old definition of the test function was replaced with the new definition. Although the change was to the logic of the function, it could have just been a change to formatting. The underlying scripting engine isn't comparing the newly added code character-for-character; it finds and updates any overlapping functions, globals, etc. that exist in the engine. New functions, globals, etc. are simply added to the current set of items already in the engine.
Which leads to the final issue — how to remove code from the Script Control. Unfortunately, the Script Control (actually, the underlying Active Scripting engine) has no means to remove added code. Once there, it's there. Using the native Active Scripting interfaces, you could clone the engine and start again, but you'd still have to decide whether you wanted to include all of the script in the engine or none of it — there's no partial copying.
However, there is a workaround that may offer some simple deactivation of script. Since a function can be added multiple times to the engine, replacing any duplicated items, a function could be clipped to do nothing, as in the following:
sc.AddCode( "function test(x,y) { };" );
The function is still there but doesn't do anything anymore. This could be done across a suite of no-longer-needed functions within a running Script Control. It's not as clean as being able to remove code directly, but alas the Active Scripting engines don't provide for this capability.
Another approach would be to have a master function that calls dependent functions. Add new dependent functions and re-add the master function, which now calls the new ones. The older dependent functions would still be there, but would no longer be used. Although this would work properly, it would cause obvious problems for a script debugger as the deactivated functions would still be visible to the debugger via the source code — imagine a user debugging script and seeing unused functions, or ones that had no implementation.
It's too bad Microsoft didn't add support for removing script from an engine once added. However, at least they supported the ability to change script by re-adding it.
Do you have a passion for Scripting?
If you want to access the extensive exchanges between other developers about Active Scripting, head over to Google's archive of Usenet newsgroups and read through the microsoft.public.scripting.hosting group. If you're working with the newer .NET version of scripting, you might look through microsoft.public.dotnet.scripting.
Also, if you have questions about how to use Active Scripting, I'd encourage you to read through my Active Scripting FAQ document that covers a wide range of problems other developers have had and many useful answers from their experiences. You can find it here.
Finally, a rich source of material on Active Scripting, JScript and VBScript from a true Microsoft insider is Eric Lippert's blog.
Looking for back issues of the Active Scripting newsletter?
Head over to the Dr. Dobb's Journal site to read any of the back issues on-line. The Active Scripting newsletter has now been in publication for over 4 years and you will find a wealth of information, commentary and insight that will make using and understanding Active Scripting easier and more productive.
Final Thoughts
I hope you find this newsletter a timely and helpful addition to your knowledge base about Active Scripting. Please feel free to email me at [email protected] and let me know what you think of it, ways to improve on content, and how this newsletter is helping you.
Until next month...
Cheers!
Mark
