See also ALP
- component was used to build it.
In the past years we used Active Scripting in many projects developed for our
contractors. Versions of this control or other implementations of the scripting
hosts helped us to build several interesting applications and plug-ins: GIS
server applications, Internet Explorer toolbars and toolbands, Asynchronous
Pluggable Protocols and so on. The component presented here implements the most
used hosting capabilities and simplifies the hosts implementation.
With ScriptManager2 ActiveX many existing C++ application can be extended to
host scripts for a few hours. Of course the developers can choose between simple
and very extended scripting features thus the actual amount of time needed
depends on your choice.
The primary target of the component are C++ developers, but it can be useful for
ASP programming too. It ships with a simple C++ helper classes that can speed
the development work and can help to the non-COM programmers to use the
component in their projects.
The component packs the most used Active Scripting features need by a hosting
program, provides a easy ways to build the named items collection and to add
script code. It doesn't cover everything that can be made with the Microsoft's
Active Scripting technology, but our experience shows that the features included
are the commonly used ones. We are open for the suggestions and other notes.
The new version adds more options and also adds the Script aggregate component
that allows scripts in different languages to be treated as like they are
written in one single script language.
Let make a little example - an ASP page hosts other
script using the ScriptManager2 component: Suppose you want to create a set of
export filters and send to the client some results from the DB in format the
user selects:
' Error checking is omitted for brevity
Set host = Server.CreateObject("newObjects.Scphost.ScpMan2")
' Load VBScript language processor
host.LoadEngine "VBScript"
' Get a recordset containing some data
Set db = Server.CreateObject("ADODB.Connection")
Set rst = db.Execute("SELECT * From Table1")
Set sf = Server.CreateObject("newObjects.utilctls.SFMain")
' Create the output file (using memory stream is more convenient)
Set outFile = sf.CreateMemoryStream
' Load the script which will do the extraction
Set f = sf.OpenFile(Server.MapPath(Request("ExportFilter"))
' Add the environment objects to the host
host.Add "Data", rst
host.Add "File", outFile
' Load the script into the host
host.AddText f.ReadText
host.Run
' Suppose filter script defines the content type in its global variable ContentType
Response.ContentType = host.script.ContentType
Response.BinaryWrite outFile.ReadBin(outFile.Size)
' Close files etc.
Now let see a sample export filter:
Public ContentType
' Set the content type of the produced output
' The ASP page will want to see this variable (see above)
ContentType = "text/plain"
' Enumerate the recordset and write comma delimited data for example.
While NOT Data.EOF
' Equivalent to WriteLine - writes the text and puts a at the end
' See Storages and Files objects in this pack
File.WriteText Data("Name") & "," & Data("Age"), 1
Data.MoveNext
Wend
The benefit is obvious - the filtering scripts can be many. It will be much
more convenient to prepare convenient environment for them. Then the other
developers will be able to concentrate on the filter functionality and forget
about the ASP specifics. Also the same script can be used in another
application (non-ASP) - you will need just to initialize the host in the same
manner and they will work without any change!
