Re: Syntax Error

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"Al Dunbar" <AlanDrub@xxxxxxxxxxxxxxxxxxx> wrote in message
news:OuJU%232pDIHA.4584@xxxxxxxxxxxxxxxxxxxxxxx

"Paul Randall" <paulr901@xxxxxxxxxxxx> wrote in message
news:%23Gfs%23H5CIHA.4584@xxxxxxxxxxxxxxxxxxxxxxx

<thequicks@xxxxxxxxx> wrote in message
news:1192031897.477995.280550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


< Yeah I commented that one out because it was only reading the text
< file and not actually installing anything. I moved it to the end
< thinking that would help and that is when the syntax error started.
< So where should the loop occur? Thanks for the response I am pretty
< new to this and it helps having pros like yourself to bounce this
< stuff off.

You need to understand a little how a script "works".

Nice explanation...

A simple script just seems to execute sequentially, one line after
another, from start to finish. Sample:

<start code>
MsgBox "Starting"
MsgBox "Done"
<end code>

You may think that the scripting host just scans the script once and
executes it one line at a time. In actuality, it is a little more
complex. You know something is happening because syntax errors pop up
before the script starts to execute (if you misspelled the word MsgBox in
the second MsgBox statement above, for example).

Looping mechanism can repeat groups of lines of code.

Sometimes it is convenient or logical to always run a group of lines
together, perhaps with some parameters to get the exact result you want.
You would typically enclose this group of lines in a Function ... End
Function or Sub ... End Sub structure. The function or function is NOT
executed when it is encountered in the list of statements that make up
the script; its statements are only executed when (and if) the function
or subroutine is called. Perhaps during the time that syntax is being
checked, the functions and subroutines are defined by their statements
within the script. The system doesn't care if define your functions at
random points thoughout the main body of the script, but you are not
allowed to define functions or subroutines within other blocks of code,
such as If ... Else ... End If blocks, or loops, or within other
functions or subroutines.

Example:
<Start Code>
Function Quit(sReason)
MsgBox "Quitting because: " & vbCrLf & sReason
WScript.Quit
End Function

MsgBox "Starting"
Quit "All Done"
<End Code>

Some people like to put all their functions & subroutines at the
beginning of their scripts, but I think most scripters put them at the
end. Some scripters build up a library of their functions and
subroutines that they always want to have available to their scripts and
store them all in one or more files. Near the beginning of their scrips,
they use the file system object to read these files into text strings and
use the execute or execute global statement to define the function and
subroutine code blocks contained in those strings.

Still others use the .WSF format to contain main program code and links to
their subs and functions stored in separate files...

This can make your script files relatively small while having all your
custom routines available.

Unfortunately, scripts that read in their subroutines and define them into
their code using the execute statement can be more difficult to debug.

They are no more difficult to debug than WSf-linking; I think the process is
essentially the same.

Because it is so difficult (no indication of line number or sub/function
name in which an error occurs), it is best to be quite sure you have
thoroughly debugged the code that you use in this manner, and judiciously
handle errors that are prone to occur in certain statements.

-Paul Randall

Similarly, text files containing constants that they may want defined,
like:
Const vbDefaultButton4 = 768
can be executed so that these these standard variable names can be used
in the script without having to know the exact number for that option.

-Paul Randall


.

Quantcast