I'm designing a script destined to be called from Photoshop CS2. Since I'm a
VBA programmer by proficiency, I'm coding in the familiar editing environment
of Excel's VBE. When I translate the final module to VBS, how do I account
for references I set to other libraries, namely to the Microsoft Scripting
Runtime library (C:\WINDOWS\system32\scrrun.dll)?

Is there something similar to C++'s #DECLARE statement, or is there
something different to do? I suppose I could just create
FileScriptingObjects, but I prefer to work with object libraries.

Thanks,
Matthew Pfluger

On May 6, 9:04 am, Matthew Pfluger
wrote:
I'm designing a script destined to be called from Photoshop CS2. Since I'm a
VBA programmer by proficiency, I'm coding in the familiar editing environment
of Excel's VBE. When I translate the final module to VBS, how do I account
for references I set to other libraries, namely to the Microsoft Scripting
Runtime library (C:\WINDOWS\system32\scrrun.dll)?

Is there something similar to C++'s #DECLARE statement, or is there
something different to do? I suppose I could just create
FileScriptingObjects, but I prefer to work with object libraries.

Thanks,
Matthew Pfluger

All objects in VBS are late bound. As I understand it, that means you
MUST *explicitly* bind to any and all objects/classes you intend to
use. Specifically, this almost universally means SETting a variable
using the CreateObject() method and then referencing all properties
and methods to that variable. There is a GetObject() method, but this
has limited applicability. One convenient way to make the re3ference
is with the WITH/END WITH block. Then your reference to the property
just needs to prefix the item's use with a dot.

Another thing that needs to change is the use of intrinsic constants
from 'library' objects. Unless the XML script implementation WSF file
is used, where an <object tag can gain access to these constants, any
you need will have to be explicitly defined.

Also, named and optional function/sub arguments are NOT supported.
That is the Name:= construct needs to be removed and all arguments,
blank or not need to be provided in the order they are defined in the
base argument list.

There is also no DoEvents support, so in most cases multi-threading is
not supported (unless an asynchronous Run is used to launch another
script/application).

There is no strong typing - all variables are of type Variant, so
variable declarations with AS clauses are not supported. Any such
references will need to be removed or commented out.

Userforms are not supported, event handling requires special handling
- none are intrinsically supported - and all scripts need a main body
that invokes the needed subroutines as appropriate.

I'm sure there's more, but that's what comes to mind off the top of my
head.

One final comment: Unless I plan on using a lot of Excel's
functionality, I tend to build VBS in a plain text editor - or maybe
in the Office MSE7 IDE - because it tends to keep me straight with
regard to these issues. I DO work in the Excel environment when using
the Macro Recorder will speed the application's development and then
translate to VBS to build the stand alone.

HTH,

Tom Lavedas
===========
http://members.cox.net/tglbatch/wsh/

Tom,

Thanks for your incredibly informative post. I appreciate the help. This
will be my first crack at a VBScript, and I appreciate the help. When you
say you tend to code in MSE, do you just create a new file and then export to
a *.vbs file? Can you offer any other references you use for VBS coding?

Thanks,
Matthew Pfluger

P.S. The late binding and strong variable type rules are disturbing...

"T Lavedas" wrote:

On May 6, 9:04 am, Matthew Pfluger
wrote:
I'm designing a script destined to be called from Photoshop CS2. Since I'm a
VBA programmer by proficiency, I'm coding in the familiar editing environment
of Excel's VBE. When I translate the final module to VBS, how do I account
for references I set to other libraries, namely to the Microsoft Scripting
Runtime library (C:\WINDOWS\system32\scrrun.dll)?

Is there something similar to C++'s #DECLARE statement, or is there
something different to do? I suppose I could just create
FileScriptingObjects, but I prefer to work with object libraries.

Thanks,
Matthew Pfluger

All objects in VBS are late bound. As I understand it, that means you
MUST *explicitly* bind to any and all objects/classes you intend to
use. Specifically, this almost universally means SETting a variable
using the CreateObject() method and then referencing all properties
and methods to that variable. There is a GetObject() method, but this
has limited applicability. One convenient way to make the re3ference
is with the WITH/END WITH block. Then your reference to the property
just needs to prefix the item's use with a dot.

Another thing that needs to change is the use of intrinsic constants
from 'library' objects. Unless the XML script implementation WSF file
is used, where an <object tag can gain access to these constants, any
you need will have to be explicitly defined.

Also, named and optional function/sub arguments are NOT supported.
That is the Name:= construct needs to be removed and all arguments,
blank or not need to be provided in the order they are defined in the
base argument list.

There is also no DoEvents support, so in most cases multi-threading is
not supported (unless an asynchronous Run is used to launch another
script/application).

There is no strong typing - all variables are of type Variant, so
variable declarations with AS clauses are not supported. Any such
references will need to be removed or commented out.

Userforms are not supported, event handling requires special handling
- none are intrinsically supported - and all scripts need a main body
that invokes the needed subroutines as appropriate.

I'm sure there's more, but that's what comes to mind off the top of my
head.

One final comment: Unless I plan on using a lot of Excel's
functionality, I tend to build VBS in a plain text editor - or maybe
in the Office MSE7 IDE - because it tends to keep me straight with
regard to these issues. I DO work in the Excel environment when using
the Macro Recorder will speed the application's development and then
translate to VBS to build the stand alone.

HTH,

Tom Lavedas
===========
http://members.cox.net/tglbatch/wsh/

On May 6, 11:18 am, Matthew Pfluger
wrote:
Tom,

Thanks for your incredibly informative post. I appreciate the help. This
will be my first crack at a VBScript, and I appreciate the help. When you
say you tend to code in MSE, do you just create a new file and then export to
a *.vbs file? Can you offer any other references you use for VBS coding?

Thanks,
Matthew Pfluger

P.S. The late binding and strong variable type rules are disturbing...

{snip}

Concerning MSE, I tend to start with a .vbs file and open it in the
IDE, but you can do it the other way. The Intelli-sense doesn't kick
in until you provide a file type, so open a new project and
immediately save it to a .vbs file. Debugging in the IDE is a bit
problematic, because the script needs to run under the WSH host, which
the IDE does not support, AFAIK. I tend to just save the file and
then launch it from Explorer and deal with the syntax and runtime
errors as they pop up. But, that's me - I'm sure others link to the
script debugger and do it that way - its just that I've never stopped
to figure it out - I get along with the trial and error approach,
instead.

Relative to references for scripting, Mr. Alcatel has provided a good
cross reference in his response to ypur post. In addition there are
the items below:

Microsoft® Windows®2000 Scripting Guide (URL all one line)
http://www.microsoft.com/technet/scr...e/default.mspx

TechNet Script Center Sample Scripts (URL all one line)
http://www.microsoft.com/downloads/d...a-b8814fe2da5a

WSH 5.6 documentation download (URL all one line)
http://www.microsoft.com/downloads/d...displaylang=en

Tom Lavedas
===========
http://members.cox.net/tglbatch/wsh/

This may be helpful:
http://msdn.microsoft.com/en-us/libr...c7(VS.85).aspx

"Matthew Pfluger" wrote in
message ...
I'm designing a script destined to be called from Photoshop CS2. Since
I'm a
VBA programmer by proficiency, I'm coding in the familiar editing
environment
of Excel's VBE. When I translate the final module to VBS, how do I
account
for references I set to other libraries, namely to the Microsoft Scripting
Runtime library (C:\WINDOWS\system32\scrrun.dll)?

Is there something similar to C++'s #DECLARE statement, or is there
something different to do? I suppose I could just create
FileScriptingObjects, but I prefer to work with object libraries.

Thanks,
Matthew Pfluger