Vista - Calling external Subs and Functions

It says here that Public Sub "indicates that the Sub procedure is accessible
to all other procedures in all scripts". That sounds to me like I can write
x.vbs and have it call a Public Sub residing in y.vbs. But how? What's the
syntax for calling it? Is there a special procedure for making it known to
the script host? Can they be in different folders as well as different .vbs
files? How does this work, and/or where is it documented?

It says "here"?

Public is used in a class, making the given method
visible from outside the class. In basic scripts (not
classes) any sub or function has global scope, meaning
that it can be called from anywhere else in the process.
Public and Private keywords are not used in that case.
Usually global scope means it can be called from anywhere
else in the script. If you have an HTA and include scripts
with:
<SCRIPT SRC="outsidescript.vbs" LANGUAGE="VBScript></SCRIPT>

then global scope for the HTA also includes the external .vbs file.

You can also use ExecuteGlobal with any code. If you
open a second .vbs file as a Textstream, then read out the
entire content into a variable (s = TS.ReadAll) you can
then call: ExecuteGlobal s
That adds the new code to your script process, as though
you had pasted the content of the second file into the first.
That's what you would need to do with the file y.vbs.

There is one way you can call to external files, which is
script components (.wsc files):
http://msdn.microsoft.com/en-us/libr...bt(VS.85).aspx

That involves writing methods in a .wsc text file,
wrapped in some rather clunky XML, and then registering
the file as though it were a COM DLL. The result is that
you get the ability to create your own custom-written
objects from any script.

The disadvantages of .wsc:

- You have to write the XML wrapper.
- You have to register the file.
- Registering text files as COM libraries is a questionable
and somewhat hokey practice. It means that your object
will end up listed in the Registry under HKCR as though it
were a system file and you'll need to make sure you
don't move it.
accessiblewritetheto..vbs

"Bob Bridges" <rhbridg.RemoveThisNode@xxxxxx> wrote in message
news:83AF4924-7B98-4DA2-AF65-E83408071A67@xxxxxxHere is an example:
http://www.naterice.com/blog/templat...link.asp?id=53

That's interesting, Pegasus (really, I mean, not facetiously), and thanks,
but it doesn't seem to be an example of the capabilities of the Public
Sub statement I quoted from the VBS documentation. Is there an
example of something in that line?

--- "Pegasus (MVP)" wrote:

In the VBS documentation, I mean, my C:\WINDOWS\system32\VBSCRIP5.CHM.

As for the clunkiness of .wsc writing, I've looked it up and I see why you
say so. But for someone like me it looks as though it may be worth it.
Nothing do I know about XML, but I've got to learn some time; and if I'm
careful to design a good place for all my common VBS classes, then my
penchant for writing all sorts of tools for myself may be useful in VBS as it
is in various other languages and platforms.

The VBS doc didn't say anything about Public being used only within class;
it just said it makes the Sub accessible in all other scripts. But from
clues in your answer I suspect there's an assumption we're not sharing: I
write my "scripts" in text files.vbs, whereas I'll bet both you and the VBS
documentation are assuming they're embedded in HTML or other documents.
Without that understanding, my next question is something like this: "What
could it possibly mean by 'all scripts' if not 'all those script files I have
lying around in my various folders'?". I grant you the Microsoft technical
writers are not given to making assumptions, but if they missed this one it
would give this whole thing meaning If they're thinking of scripts as being
bits of VBS code embedded in a web page, then their statement makes sense
even if I'm not able to do what the documentation seems to claim.

So am I on the right track now? Both you and the VBS documentation mean by
"all scripts" that any code in a web page can access a sub in any other bit
of code in the same page? but this doesn't apply to scripts in text.vbs files?

--- "mayayana" wrote:

"mayayana" <mayaXXyana@xxxxxx> wrote in message
news:OI7wiq2GJHA.3504@xxxxxxCorrection: "Public and Private keywords are *generally* not used in that
case."

The Public and Private keywords *can* be used outside of a class definition,
however, they have no effect at all on the scope of the components they
describe.

I sometimes use "private" to define a global variable that, logically,
belongs to one specific function or sub to provide "persistence. The value
(to me, at least) of using Private instead of DIM is to document this
intent.

/Al

"Bob Bridges" <rhbridg.RemoveThisNode@xxxxxx> wrote in message
news:FA0BBA99-5ADB-4D4C-A1C5-6C800D6F704F@xxxxxxhint: with the right editing tools, you need know NOTHING about XML in order
to make effective use of the .wsf format. PrimalScript, for example, allows
one to create and edit scripts in .wsf files with little to no knowledge of
the XML keywords used.
The .wsf (xml) format makes it much easier to build library routines (and
stored in their own .vbs files) shared by multiple WSH scripts (stored in
..wsf files), as there is no need for an executable INCLUDE function (which
works, but can complicate the debugging process), or, _shudder_ by including
pasted copies of library routines directly in .vbs files (which makes it
harder to update the client scripts when a new version of a library function
has been developed).
I struggled with that little omission in the documentation years ago... It
is not the only one, of course, but perhaps the most obvious (once you know
it is an error).
Not so. The VBS documentation errs as you suggest by not mentioning that the
PUBLIC and PRIVATE keywords really only apply to code within a class
definition - regardless of script file format or the scripting engine used.
Yikes, I hope not! If that were true, then one would need to ensure that
variable, const, sub, and function names must be completely unique in all
scripts stored on your computer, to say nothing of the CPU cycles that would
be used to find all instances of undefined functions in all your other
scripts, and determine which one of the same name is intended...

But seriously, I think it means all scripts in the global scope of the
currently running script. And here I think the word "scripts" to have been
poorly chosen. I would have written it differently, as:

"Public Sub indicates that the Sub procedure within the class is accessible
to all other procedures in the currently executing script, whether or not in
the same class"
They did not make an assumption, they made an error.
Their statement does not make sense, as it is, simply, in error. Or at
least, seriously misleading in nature.
The VBS docs refer principally to the VBScript language, rather than to
script being processed by any particular scripting engine, whether that be
WSH, HTA, HTML, or what have you. Whether or not the instances of two
separate code blocks are in the same scope would seem to be more the
responsibility of the scripting engine to define.

For example, in the .WSF format, separate <SCRIPT> blocks within the same
<JOB> interact with each other as if they were all in the same .vbs file.
<SCRIPT> blocks in one <JOB> have no access to <SCRIPT> blocks in other
<JOB>s in the same file (or any other file, for that matter). - unless of
course the script opens those files to read in the script code located
there.

This distinction is not covered in the VBS docs, but in the WSH docs, where
it properly belongs.
Incorrect. IMHO, the PUBLIC/PRIVATE keywords apply to class definitions in
vbscript in *any* file type or as run by any scripting engine that process
VBScript code.

But that is not even the worst of it. Due to a coding error, constants and
arrays defined in class code outside of internal subs and functions are not
actually created, however the code is not flagged as an error.

In summary: neither the docs nor the scripting engines themselves are
perfect, and one must adapt to these little quirks of theirs. The
alternatives include waiting for the problems to be corrected or searching
for a scripting architecture that has no flaws. I don't know about you, but
I cannot wait that long... ;-)


/Al

<snip>

> but it doesn't seem to be an example of the capabilities of the PublicThe documentation is simply wrong. I found the
line you mentioned:

"Public statement variables are available to all procedures in all scripts."

It's wrong and it doesn't make sense unless you interpret
"in all scripts" to mean "without exception".