Re: More than one vbs file

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Sofia Engvall (ask_at_ask.ask)
Date: 01/17/05 

Date: Mon, 17 Jan 2005 13:09:48 +0100

"Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com> wrote in message
news:eQZkpxs%23EHA.3616@TK2MSFTNGP11.phx.gbl...
> "Sofia Engvall" <ask@ask.ask> wrote in message
> news:%231gsFFW%23EHA.2180@TK2MSFTNGP12.phx.gbl...
>> "Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com> wrote in message
>> news:ORjISHT%23EHA.3988@TK2MSFTNGP11.phx.gbl...
>> > "Sofia Engvall" <ask@ask.ask> wrote in message
>> > news:%23zHMfAM%23EHA.1452@TK2MSFTNGP11.phx.gbl...
>> >> "Michael Harris (MVP)" <mikhar@mvps.org> wrote in message
>> >> news:OOclsvL%23EHA.600@TK2MSFTNGP09.phx.gbl...

>>>>>> So you're saying there's no way to do it if you don't want to use
>>>>>> .wsf? Sounds unbelivable!!! There must be a way!?
>>>>> Why would you *not* want to use *.wsf if it easily solves your
>>>>> problem?
>>>> Just a feeling i guess ;-) And lack of knowledge...
>>>> Habbits die hard.
>>> Just keep saying to yourself: WSH and KIX are quite different... WSH and
>>> KIX
>>> are quite different... WSH and KIX are quite different...
>> He he... :D
>>
>>> Then consider that, since a bicycle and an airplane are quite different,
>>> the
>>> methods and skills used to drive them are quite different in the detail.
>> Yup, but most languages have such a funcion so I was very suprised. This
>> is
>> more like an autopilot when I'm used to steering myself. :)
>
> Most languages? Have you done a survey of them? Of all of the languages I
> have ever used, the MINORITY had a literal include capability. Those WITH
> a
> literal include:

No, of course I haven't done a survey. :)
And I mean the languages I use most frequentlly (c, c++, vb.net, (kixtart,
batch)).
And the functionallity I mean is not a "literal include" but a capability to
use several files and I guess vbs has that in a way in wsf.

Would you be depressed if Microsoft did implement the functionality to run
one vbs from another without doing it in another process? All I say is that
I would be quite happy myself. :)

> I am being facetious, of course, but there is still a significant
> difference
> between including code from another source and executing code from another
> source. In the assemblers I mentioned, the includes are processed at
> assembly time. By the time you get to execution time the assembly has been
> done, and the content of the executable makes no distinction between the
> included code and the inline code. So, the included code is not executed
> when it is included, just assembled.

Yes, that is what I meant be c-style include. :)
You still get an error at compile time though, with line and position, if
there's an error in an included file.

> Yes. Even earlier in my career when I was developing programs for other
> researchers to use, they used to joke that there needed to be a "Hey Al!"
> button on the keyboard because they were calling me so often. When I
> realized how often I was being called, I soon realized that I was one of
> my
> own subroutines!

:-D

> My turn to laugh - been there, done that. Actually, none of our policies
> are
> made to be broken. They are made to be followed, but contain enough flaws
> that, once implemented, it turns out that they have to be broken. A fine
> distinction, perhaps, but then what good is a nit if it can't be picked?
> :-)

I guess this applies to just about everything... Good intensions but... :)

>>>> Though I intend to move the functions to other files when they are done
>>>> you'll always make a few updates and miss a char here 'n there...
>>> Don't move them into statically included .vbs file, create them there in
>>> the
>>> first place. In addition to the above noted problems, calling a sub in
>>> an
>>> INCLUDED file requires a number of additional steps beyond that of the
>>> .wsf
>>> format, each of which can fail for a number of reaons.
>>
>> What steps? I guess I'll have to test it just to have done it if nothing
>> else... :)
>
> The steps I mention (and reasons for failing) are:
>
> 1) to read in the included file: the name might be incorrect or the file
> might be unavailable because someone is editing it.
>
> 2) to execute the read-in code with an EXECUTEGLOBAL: there might be
> syntax
> errors in the code that will not have been diagnosed when the original
> script was read in and compiled.
>
> 3) to call a subroutine that is assumed to have been defined in the
> included
> file, but which might not be, perhaps because of a spelling error.
>
> In general, if ALL of the code appears either within the embedded <script>
> blocks or in files included by a <script scr="name"> tag, the equivalent
> of
> the above errors may occur, but will be more logically reported by the
> scripting host.

So it comes down to by the error reporting that's the difference again. I
thought you meant you had to do something special when you called the
functions or something but I didn't se how. But don't worry, you've
discouraged me enough not to use include. ;-D

Thanks Al! :-)

/Sofia

Quantcast