Global module limit of size of text?

I have a process that combines many vb functions into a single String
object.
This is then added to the VBScript control via the AddCode method.
Implicitily this becomes part of the global module.

When the script runs i start to get errors - because some of the
functions are missing.
This happens when the text reaches a certain limit.

So is there a limit on the text that you can add to the global module?
How can i resolve this problem?

Thanks.

mr_unreliable
Fri Jul 20 12:12:18 CDT 2007

Herby wrote:
> So is there a limit on the text that you can add to the global module?
> How can i resolve this problem?

hi Herby,

Well yes, obviously there is a limit. And apparently you have
run up against it. I don't know the limit, but the script
control was written back in 2001, when memory sizes were
measured in mega-bytes rather than giga-bytes.

And I don't see any methods or properties which would allow
you to increase size of the global module code buffer.

So, here's my suggestion. Break up your blob into discrete
"modules", in the approved object-oriented way. Then make
those modules available to the script control. I am guessing,
but I think that with this approach you can add as much code
as you like (that is, until you run up against the limit for
the number of added modules).

In a demo I wrote a while back, I added a "WScript" class to
the script control, to make up for the lack of the availability
of the wscript object in scripts intended to be run inside the
script control. Here is some code:

--- <snip> ---
' note: in this code, scScript is the name of the script control...

Dim oWScript As New clsWScript ' contains some wscript methods
Dim oModule As New clsModule ' contains some other methods

With scScript ' initialize the script control...
.AllowUI = True ' allow script to display user interface (ex: MB)
.Language = "VBScript"
End With

' set up the object references...
scScript.AddObject "WScript", oWScript, True
scScript.AddObject "scModule", oModule, True

--- </snip> ---

Note that the "clsWScript" and "clsModule" are included in the
project as "class modules", with the "cls" extension.

Also note that once you have made your (class) modules
available to the script control, then you can use the module's
methods and properties in the script running in the script
control by using the name you have given. For example,
to use the clsWScript code in the script, I gave it the
name "WScript". And to use the clsWScript's "sleep" method,
I would have written "WScript.Sleep" in my script.

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)

Herby
Mon Jul 23 03:23:17 CDT 2007

On 20 Jul, 18:12, mr_unreliable <kindlyReplyToNewsgr...@notmail.com>
wrote:
> Herby wrote:
> > So is there a limit on the text that you can add to the global module?
> > How can i resolve this problem?
>
> hi Herby,
>
> Well yes, obviously there is a limit. And apparently you have
> run up against it. I don't know the limit, but the script
> control was written back in 2001, when memory sizes were
> measured in mega-bytes rather than giga-bytes.
>
> And I don't see any methods or properties which would allow
> you to increase size of the global module code buffer.
>
> So, here's my suggestion. Break up your blob into discrete
> "modules", in the approved object-oriented way. Then make
> those modules available to the script control. I am guessing,
> but I think that with this approach you can add as much code
> as you like (that is, until you run up against the limit for
> the number of added modules).
>
> In a demo I wrote a while back, I added a "WScript" class to
> the script control, to make up for the lack of the availability
> of the wscript object in scripts intended to be run inside the
> script control. Here is some code:
>
> --- <snip> ---
> ' note: in this code, scScript is the name of the script control...
>
> Dim oWScript As New clsWScript ' contains some wscript methods
> Dim oModule As New clsModule ' contains some other methods
>
> With scScript ' initialize the script control...
> .AllowUI = True ' allow script to display user interface (ex: MB)
> .Language = "VBScript"
> End With
>
> ' set up the object references...
> scScript.AddObject "WScript", oWScript, True
> scScript.AddObject "scModule", oModule, True
>
> --- </snip> ---
>
> Note that the "clsWScript" and "clsModule" are included in the
> project as "class modules", with the "cls" extension.
>
> Also note that once you have made your (class) modules
> available to the script control, then you can use the module's
> methods and properties in the script running in the script
> control by using the name you have given. For example,
> to use the clsWScript code in the script, I gave it the
> name "WScript". And to use the clsWScript's "sleep" method,
> I would have written "WScript.Sleep" in my script.
>
> cheers, jw
> ____________________________________________________________
>
> You got questions? WE GOT ANSWERS!!! ..(but,
> no guarantee the answers will be applicable to the questions)



Thanks Mr Unreliable.
I hope i can rely on your proposed solution.

If i break my set of vb functions down into different modules, will
the function calls within the script have to be prefixed with the
module name?

E.g.

Where currently we have

call function1()

Will this have to be replaced with

call module1.function1()

This latter approach will require considerable editing of the existing
scripts. Plus all want to hide the adding of functions to modules
automatic and hidden from the script writer.

mr_unreliable
Mon Jul 23 15:39:05 CDT 2007

Herby wrote:
> If i break my set of vb functions down into different modules, will
> the function calls within the script have to be prefixed with the
> module name?
>
> E.g.
>
> Where currently we have
>
> call function1()
>
> Will this have to be replaced with
>
> call module1.function1()

sorry, but yes. (note that you don't need the "call", simply
use myObject.myMethod followed by parameters, if any).

>
> This latter approach will require considerable editing of the existing
> scripts. Plus all want to hide the adding of functions to modules
> automatic and hidden from the script writer.

Herby, as best I can tell, you can only cram so much into the
script control's global module buffer, and you have surpassed that.

If breaking your blob up into modules (a.k.a., vb classes) is
unacceptable, the only other alternative is to get out your wallet,
go on bended knee to microsoft, and keep throwing $1,000 bills on
the table until the pile is big enough to cause microsoft to relent
and increase the global module buffer size for you.

Or, you could write your own script control. It shouldn't be
too hard, just set up a buffer, load your code into it and call
vbscript.dll to run it. OK, ok, before all you flamers come out
with your blowtorches and start scorching my backsides, it's
probably more complicated than that, but that is the essence
of it.

Pssst. There's another way, but don't tell anybody, especially
microsoft. You could "reverse engineer" the script control, i.e.,
dis-assemble it. You can find a number of dis-assemblers on the
web. After you dis-assemble it, you find where the buffer is
allocated, and re-allocate it so that it will hold your blob.
Or better yet, recode it so that you can specify the global module
buffer size as a parameter. Then just assemble it again.
Unfortunately, microsoft does not take kindly to people who
reverse engineer their code, and if you are discovered, you
can expect to promptly hear from microsoft's lawyers. Then
your wife and children should prepare for you go be gone for
a long time.

Another possibility -- if you happen to have a generous software
budget -- is to buy the VBA package from microsoft, and install
that in your app. VBA is much more capable than vbScript anyway.
Your users may be happy to suffer the conversion to VBA...

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)

mr_unreliable
Mon Jul 23 16:12:17 CDT 2007

mr_unreliable wrote:
> Or, you could write your own script control.

If you are interested in writing your own script control,
I recommend reading this blurb from Leonid Belkind, entitled:
"Microsoft Script Control - What is it and who should use it",
found here:

http://www.codeguru.com/cpp/com-tech/atl/scripting/article.php/c15/

--- <quote> ---
If you want to work with Microsoft Script Control, you'd better
understand it's internal functionality (at least on a high level).
Microsoft Script Control has an implementation of IActiveScriptSite and
IActiveScriptSiteWindow interfaces. It provides wrapping for some of the
IActiveScript methods. It also bubbles some of the events recieved via
IActiveScriptSite interface to a Script Control host using Error and
Timeout events. Access to all Active Scripting features is very
simplified. For example: to add a named object to a scripting
environment you only need to call ScriptControl.AddObject instead of
calling IActiveScript::AddItem and implementing quite a complicated
IActiveScriptSite::GetItemInfo. When the Language property of Script
Control is set, it calls CoCreateInstance with a matching engine CLSID
and "forwards" all information supplied by user to a Scripting Engine.
--- </quote> ---

And the "IActiveScript" interfaces are all described in your
scripting documentation. You may have wondered why they are
there. Now you know.

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)

mr_unreliable
Fri Jul 27 12:29:50 CDT 2007

mr_unreliable wrote:
> Or, you could write your own script control.

If one is determined to write their own script control,
(say in order to make up a larger "global module"), then
take a look at this "Visual Developer" article from the
microsoft systems journal (oct99) by George Shepherd.

http://www.microsoft.com/msj/1099/Visualprog/visualprog1099.aspx

The article describes how to write a "script control",
using the IActiveScript interfaces, as described in your
scripting documentation. There is also code, although
it is c++ code, rather than vb code which might have been
more friendly. However, ms is a c++ shop, after all vb is
a "toy language" and microsoft is a serious business. The
code may be downloaded -- see the link to "Oct99VP.exe"
(a self-extracting zip file).

Note that "a" script control is not necessarily "the" script
control (msscript.ocx). However, all the interfaces are
there, so enjoy.

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)

mr_unreliable
Mon Jul 30 13:21:42 CDT 2007

mr_unreliable wrote:
> Or, you could write your own script control.

I've been searching for about a week, looking for either:
(1) a way at getting to the internals of the ms script
control, _or_ (2) a way of using the IActiveScript interfaces
from a language that I can understand ("classic" vb, rather
than c++ or c#), to host script code directly. This latter
approach (IActiveScript interface) would allow one to host
scripting DIRECTLY, without using the ms script control.

And I finally found it, on "Planet Source Code", here:

http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=50302&lngWId=1

That link points to a posting by "dzzie" entitled:
"VB IActiveScript (No Ocx Scripting)" -- in other words
using the IActiveScript interface directly. "Dzzie" also
goes by the more formal name of "Venture Digital Mfg",
and has posted his code on his own website too:

http://sandsprite.com/openSource.html

(click on "misc", then "vb IActiveScript".

Dzzie's demo code does what it says.

It goes without saying (but I'll say it anyway), that if
you deal with the interfaces directly, then you can set
up your own "global module" (and any other module for that
matter) to be as big as you wish.

Probably by now the O.P. is long gone. But for anybody
else that may stumble on this, Dzzie's typelib is invaluable
for using IActiveScript from vb. And for diehard "do-it-
yourselfers" who wish for a "better" script control than
microsoft's, or just something _different_ from ms's control,
then this is a way to get at it.

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)

mr_unreliable
Tue Jul 31 12:34:19 CDT 2007

Herby wrote:
> So is there a limit on the text that you can add to the global module?
> How can i resolve this problem?
>
Herby, your o.p. indicated problems with a blob of code
being entered into the "global scope" of the script control.

I suggested that maybe you had exceeded some internal buffer
space, which might be circumvented by using the AddObject
method to add "objects" (or instances of class code) to
extend the amount of code you could insert into the
script control.

You said that you suspected that the "object's" methods and
properties would have to be prefixed with the name of the
object (myObject.myMethod), and this additional burden of
coding script was unacceptable to your users.

There may be some hope of circumventing this, based on some
careful reading of Francesco Balena's article: "Exploring
the Microsoft Script Control", found here

http://www.microsoft.com/mind/0799/script/script.asp

--- <quote> ---
Things become more exciting when you pass an object to the
AddObject method and specify that the object is to be
considered _global_ in the script, which you do by passing
a third argument equal to True:

Dim clsShared As New SharedClass
ScriptControl1.AddObject "oSHC", clsShared, True

A global object doesn't need to be referenced explicitly when
invoking its properties and methods, which means that the
properties in SharedClass now appear to the script as regular
variables, and that the methods in the class can be now invoked
as regular VBScript procedures and functions.
--- </quote> ---

Uh-oh. Is this some undocumented feature that I missed? Well
no, it was there all the time. Look it up in your msScript.ocx
documentation.

--- <quote (in part) > ---
ADDOBJECT METHOD

Syntax

ScriptControl.AddObject(name, object[, addMembers])

The AddObject method has these parts:

Part Description
---- -----------
name Required. Name by which the added object is to be
known in ScriptControl code.

object Required. Name of the object exposed at run time.

addMembers Optional. Boolean value. True if members of object
are GLOBALLY ACCESSIBLE; False if they are not.
--- </quote> ---

In summary, there is a way, using AddObject to add code to the
script control's "global module" (code).

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)