Sub ASimpleScript()
MsgBox "Hello from VBScript!"
End Sub
Selecting it and clicking the Run Script button produces the output shown in Figure B.
| Figure B |
 |
| The anticlimactic result of running ASimpleScript.vbs |
Let's move on to something a little more impressive and take a closer look at the code behind the form's Load event (Listing A). It includes the following two lines:
ScriptControl1.AddObject "Customers", oCustomers, True
ScriptControl1.AddObject "Output", oScriptOutput, True
We haven't talked about AddObject yet. It allows you to add references to objects to the script control's execution environment. Objects added in this way become globally accessible to all scripts run by a control, giving a script access to objects created by your application and a way to communicate with your application. In this case, we add a reference to the collection of play data created when the main form loads as Customers, along with an instance of the Output class, which gives scripts write-only access to txtOutput on the main form. You can see the usefulness of this by examining the code for the EnumCustomer script, which appears in Listing B. The script accepts a single input argument, which represents the index of a customer contained in the Customers collection that we added to the script control's environment via a call to AddObject. The script accesses the Customers collection and enumerates all the available fields of the selected item, printing the results in txtOutput via the Output object. It's a two-way street
One question that's likely forming in your mind now is, why wrap txtOutput in a class instead of just adding a reference to frmMain.txtOutput via AddObject? Check out UpdateCustomer.vbs for an answer to that question:
Sub UpdateCustomer(num)
Output.PrintLine("Changing ")
Output.PrintLine(Customers(num).ContactName )
Output.PrintLine(" to Bob Hope")
Customers(num).ContactName = "Bob Hope"
End Sub
This script modifies the contents of an item in the Customers collection, which means that scripts have read and write access to objects added to their environment via AddObject. A mischievous script could do something like this, were I to allow it unfettered access to txtOutput:
txtOutput.Visible = false
This behavior would cause troubles for any subsequently run scripts that attempted to communicate with the user via txtOutput. While I haven't been able to create a script that could successfully change the actual reference of one of the global objects added by AddObject (like Customers=Nothing), I won't go so far as to say it's not possible. So the moral here is to be careful about the access you provide to scripts. Explore the possibilities
An obvious area where a scriptable application could be useful is end-user customization and automation. A less obvious application could be the use of scripts for temporary bug fixes. With a little ingenuity, it would be possible to provide hooks for scripts to be run on the occurrence of certain application events. Then, you could simply distribute a script that corrects the effect of an application bug, instead of having to distribute a new binary immediately. Custom reporting and data analysis could also be provided in this fashion
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
