Archive of UserLand's first discussion group, started October 5, 1998.
Multiple Script Control Instances
Author: Jim Roepcke Posted: 12/21/1998; 12:44:36 PM Topic: Getting the URL of the Front IE Window w/ VBScript Msg #: 1591 (In response to 1583) Prev/Next: 1590 / 1592
Looking at the parameters for com.callScript, I am guessing each call to callScript gets it's own instance of the Script Control, since the language (VBScript) is passed in, and that's a property of the ScriptControl class.I think a more flexible solution, still only using the ScriptControl, would be to allow a developer to create a Script Control object (call it a namespace for this example) that would persist in a separate thread until destroyed. Other Frontier threads could add and execute procedures from this namespace.
The ScriptControl object of the ScriptControl component has the following methods:
AddCode(Code As String) - Add code to the global module
AddObject(Name As String, Object As Object, [AddMembers As Boolean = False]) - Add an object to the global namespace of the scripting engine
Function Eval(Expression As String) - Evaluate an expression within the context of the global module
Sub ExecuteStatement(Statement As String) - Execute a statement within the context of the global module
Sub Reset() - Reset the scripting engine to a newly created state
Function Run(ProcedureName As String, ParamArray Parameters() As Variant) - Call a procedure defined in the global module
Those methods could equate to the following verbs:
com.startNamespace(language) - creates an instance of the ScriptContorl and returns some sort of reference to it (a longType?)
com.addCode (namespace, scripttext) - adds a procedure to a namespace
com.run (namespace, procName, paramList) - runs a procedure in the namespace and returns its return value
com.endNamespace(namespace) - destroys the namespace instance
Perhaps there'd be eval and reset too, but that's extraneous for this example.
With this set of verbs, multiple Frontier threads could share the same VBScript code objects, and COM objects, which would make execution MUCH faster, take less RAM, and also make it possible to share COM objects between threads. You also wouldn't have to create and tear-down ScriptControl objects every time you ran a procedure, which is a *very* costly process.
The current callScript verb implemention is probably doing the equivalent of:
local (rc) // will hold the return value
namespace = com.startNameSpace(language);
com.addCode (namespace, scripttext);
rc = com.run (namespace, procedureNameOf(scripttext), {p,a,r,a,m,s})
com.endNamespace (namespace);
return (rc)
With a persistent namespace, you'd only need to call com.run if the procedure was already in the namespace.
Jim
This page was archived on 6/13/2001; 4:46:52 PM.
© Copyright 1998-2001 UserLand Software, Inc.