Adds an interface pointer (object in script
terminology) to the namespaces collection. Allows caller to specify
options parameter can be one of the following constants:
0 - (default). Adds the item in the same manner as the Add
1 - like 0 but declares the item as event source. An object
firing events to the script.
2 - Adds the item as "global library". Each
method of the object becomes a part of the global functions/subs
accessible for the script. For example if the object supports a method
Print(text) then the script may refer it like this:
without specifying the object name. The name of the item is still required
- it is used if you want to remove it at later time and for internal
3 - Script host global. Add another ScriptManager2 (but
not ScriptAggregate) object
to the script namespaces. The script in this script host will be able to
call any function/sub defined in the other script directly as they are
defined in the current script. The same is true for the global variables
in the other script.
For example this allows you to "attach" to a host of a script
written in VBScript another host that holds script written in JScript and
allow the VBscript to call any function from the JScript as like they are
part of it.
If you are going to use this feature pay attention to the Public
and Private keywords in VBScript and their equivalents in the other
script languages. Routines and variables defined as Private will
not be accessible for the other script. Such features (if available in the
corresponding language) will give you better way to isolate the scripts
from each other.
4 Script host. Like previous but not global. The script
will be able to call the methods of the other script but will need to
specify the name of the item. E.g. if you added the other script host
under the name "host2" then the script will need to call its
method "someMethod" like this:
The options that add "global" objects are very useful if you
want to extend the set of core functions of the script engine. For example
you can add an object that supports some date conversion functions and
your script will see them as part of the script language itself. As you
can see this can be done with another script as well (using the option 3).
Of course using a COM object implemented in compiled language will grant
better performance but using another script as library is not so slow and
is perfect technique if the flexibility is more important.
Why not add just the script dispatch of the other script? E.g.
why not use syntax like this:
The reason is that adding the script host itself as named item
available for the script allows the script host to perform more complex
actions and also (important) there is no need the script host being
added to be started at the moment you add it! You can start it later.
Contrary if you add the script dispatch using the script property you can
do so only if the script is started because script property cannot be used
on stopped or non-initialized script.
This method can be used in any state of the script. In all cases method adds an object
to the collection used for script namespaces. When the script is not running (not yet
loaded or loaded but not started) this is the only action performed by the member. When
the script starts (By calling the Run method) all
available objects in the collection are passed to the script engine as namespaces. In
running (and connected) state AddEx method not only adds objects to the collection but adds
them to the running script namespaces too. Therefore you can add some of the namespaces in
later time when they are needed - not only before starting the script.