The developers experienced in usage of the complied languages
such as C++, Delphi or Visual Basic know about the differences
between the global variables and local variables. With ASPC such
knowledge is very important because one of the major purposes of
ASPC is the adjustment of the variable scopes in the script files
during the translation to VB. In this chapter we will try to
illustrate this process for the users with no knowledge in the
compiled languages area.
Scripts (ASP pages and other active scripts).
VBScript supports code placed outside the bodies of any
functions/subs or class bodies (called global part of the
script). This is not true for VB and most of the compiled
languages. In a VBScript file this code is executed first and any
function calls happen only if this code invokes them. Every
variable or routine defined in the global part of the
script is accessible from all the functions and classes in this
script. Thus if you have some VBScript classes defined in an
include file you will be able to use every global variable from
See this little example:
a = "Blah"
Public Sub ASub
Response.Write a & "<BR>
b ="A number" & rnd
Public Sub BSub
Response.Write b & "<BR>"
Set cls1 = New C
Set cls2 = New C
The call to the ASub will print the content of variable a
because it is accessible for the member sub.
The operator New creates an instance of the class C.
Thus the class declaration is a source of multiply instances of
the class. If you create more instances of the same class call to
the ASub of any one of them will produce the same result
because they are using the same global variable, but BSub
uses a variable b which is declared as a class member. And
its value will be separate for every instance (Here rnd
function is used and the results will be random).
Up to this point everything looks well known - life scope of a
is the entire script. Scope of the b is the class
containing it. Thus life time of the variables is bound to the
script (a) and class instance (b).
If compiled to VB the same example will define two classes: Class C
and a class for the global part of the script. The name of
the second class will be selected automatically by the compiler or
can be set using the ClassName
The corresponding loader file generated by the compiler will have a
lines like these:
Set proc = Server.CreateObject("... the name of the class
' Some initialization code
What this means? An instance of the class generated from the global
part of the script is created and a member Sub of this class is
called on it. In other words we have two different classes in the
compiled form and the global variables (and/or routines) from the
original ASP page are now members of this class. The class C remains
in different file and its instances will be created by the instance
of the other class - which packs the global part of the script.
before every class including the class created from the global
part of the script may have multiply instances. Thus variable a
cannot be accessed in the same manner as in the script.
Suppose you have several concurrent requests to this page - then
several instances of the global class will be active in memory
thus variable one a will exist as member variable in every
one of them and it will be kept in different memory block.
Therefore ASPC needs to connect every instance of the global
class (class created by ASPC from the global part of the script)
with the instances of the class C created in its members. ASPC
does this connection for you but this means the variable s is no
Well everything looks ok - why should I care
Using the DLLGlobal
directive you have a chance to make a variable declaration or
routine declaration true global declaration for the DLL created.
But this is not the same as in the script case. It can be used to
improve the performance but also may cause dangerous errors if you
are not aware what it means.
The variable (or routine) declared
with DLLGlobal directive becomes global for the DLL and it is not
a member of any class - including the global class. Thus it will
not have any access/will not be accessible for the members of the
classes. And if in the original form of the page it has the same
scope as the other global routines and variables in the compiled
DLL its scope will be different. In the DLL its scope is the DLL
and life time of the variable is the life time of the DLL and not
of a particular class/page. In other words if you assign a value
to this variable this value will be visible to all the pages
currently using the DLL- no matter which one made the change. You
can think about these variables and routines as for the
Application object in ASP. They exist in one instance for all the
objects/pages implemented in the DLL.
Therefore you should check
what variables are accessed from a routine before declaring it
DLLGlobal. If it uses any variables not passed as arguments to it
usage of the directive will not be appropriate. About the
variables the situation is similar - they will be accessible for
all the objects currently active in memory. This is ideal for the
constants but for the variables it will be good only if their
values do not depend on the particular request.