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.