Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #11788 > unrolled thread

What should one read to learn VBScript?

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  What should one read to learn VBScript? Peter Percival <peterxpercival@hotmail.com> - 2018-01-17 12:55 +0000
    Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-17 10:25 -0500
      Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-17 21:50 -0500
      Re: What should one read to learn VBScript? Wally W. <ww84wa@aim.com> - 2018-01-17 22:49 -0500
      Re: What should one read to learn VBScript? Peter Percival <peterxpercival@hotmail.com> - 2018-01-18 12:42 +0000
      Re: What should one read to learn VBScript? Peter Percival <peterxpercival@hotmail.com> - 2018-01-19 21:28 +0000
        Re: What should one read to learn VBScript? Peter Percival <peterxpercival@hotmail.com> - 2018-01-19 21:59 +0000
          Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-19 18:06 -0500
            Re: What should one read to learn VBScript? Peter Percival <peterxpercival@hotmail.com> - 2018-01-20 14:15 +0000
        Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-19 17:06 -0500
          Re: What should one read to learn VBScript? Peter Percival <peterxpercival@hotmail.com> - 2018-01-20 14:20 +0000
            Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-20 09:40 -0500
        Re: What should one read to learn VBScript? Wally W. <ww84wa@aim.com> - 2018-01-19 17:20 -0500
          Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-19 17:52 -0500
      Re: What should one read to learn VBScript? Sohel Alam <alam.sohel1990@gmail.com> - 2018-05-14 17:19 -0700
    Re: What should one read to learn VBScript? Wally W. <ww84wa@aim.com> - 2018-01-17 22:44 -0500
      Re: What should one read to learn VBScript? Peter Percival <peterxpercival@hotmail.com> - 2018-01-18 12:40 +0000
      Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-18 09:27 -0500
        Re: What should one read to learn VBScript? Special Access <nonyabidnezz@hotmail.com> - 2018-01-18 21:57 -0500
        Re: What should one read to learn VBScript? Wally W. <ww84wa@aim.com> - 2018-01-19 20:53 -0500
          Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-19 23:20 -0500
            Re: What should one read to learn VBScript? Wally W. <ww84wa@aim.com> - 2018-01-20 10:33 -0500
              Re: What should one read to learn VBScript? Wally W. <ww84wa@aim.com> - 2018-01-20 10:44 -0500
              Re: What should one read to learn VBScript? "Mayayana" <mayayana@invalid.nospam> - 2018-01-20 13:53 -0500

Page 2 of 2 — ← Prev page 1 [2]

#11804

"Wally W." <ww84wa@aim.com> wrote

| I often use wscript, but cscript can accept command line parameters.
|
| I often run cscript via a batch file.
|
| A batch file can also accept command line parameters, which may need
| to be done via a shortcut.
|
| So: It is possible to drop a file onto a batch file (or its shortcut)
| to process an input file with cscript.
|
| That way, there would be no need to respond on all the msgbox popups.
|

  I really don't get why anyone would want to go
to all that trouble, but I guess it's a matter of
personal taste. And maybe also a matter of what
you're trying to accomplish. Most of what I do is
to package some kind of functionality as a convenience
for later. It's done if I can do the job next time
without typing.

  WScript can do plenty with command line, but
I try to avoid it as much as I can.


  Here's part of something I've been updating recently, to convert
HXS files to CHM. The part below is, to me, some of the most
tedious code, but it's necessary. I'm using 7-Zip to extract the
file content of the HXS files. In brief, a folder of HXS is dropped
onto the script, which creates a custom commandline to send
to 7-Zip. It then calls a second script, zip7.vbs, and waits for
the unpacking to finish by setting the 3rd parameter of
WScript.Shell Run to True.
  The second script does the same, after building a command
line for 7-Zip out of the command string sent in, and calling
7-Zip to do the unpacking. Then the main script continues,
finishes the conversion, and starts again for the next file.

  This allows me to unpack a folder full of HXS files and convert
them all to CHM. The only msgbox is at the end, unless something
goes wrong. It just pops up and tells me how many files it
processed, to let me know it's done.

  I could do this by using a number of calls in console.
I could call 7-Zip with a command line. Then I could
call a script to process the unpacked HXS. Then I could
call the help compiler to build a CHM. But I still have to
write all that code to actually do the work. So once I've
done that, do I want to be able to just drop a folder
onto a script, or do I want to type 3 long, tricky console
lines for each HXS? Why would I do 99% of the work and
then have to do all those tricky incantations every time
I use it?

  My approach is that if I expect to be doing the same thing
repeatedly then it's worth reducing it as much as possible.
If it can be reduced to a simple drag-drop that's best.
If I had to open a console window that would mean I
didn't write the script right. :)

Below is the gist of what makes this particular utility work,
showing it for a single HXS.

sFil = WScript.Arguments(0)
'-- sFil = "C:\Windows\desktop\test2\script56.hxs"
' received from the dropped file.

SevZip = "C:\Program Files\7-Zip\7z.exe"
'-- path to 7-Zip

'-- create a subfolder for unpacking the HXS.
TempFol = "C:\Windows\desktop\test2\temp1"

' Create a comand line to send to 7-Zip to get an HXS file unpacked.
sCom = SevZip & "|" & sFil & "|" & TempFol

' Get the path where this script is running
ScrPath = WScript.ScriptFullName
Pt4 = InStrRev(ScrPath, "\")

' make the path to the second script to run 7-Zip
ScrPath = Left(ScrPath, Pt4) & "zip7.vbs"

' use WScript.Shell to send the command line to that script
' and wait for it to return.
SH.run Q2 & ScrPath & Q2 &  " " & Q2 & sCom & Q2, , True

  '----- code in zip7.vbs that receives the command. ----
' I don't actually remember why I made this external, but
' it does make it work differently. By using Run to run a
' second vbscript I do that work in a separate process.

Arg = WScript.arguments(0)
A3 = split(Arg, "|")
SevZip = A3(0)
sFil = A3(1)
Tempfol = A3(2)
 On Error Resume Next
Q2 = chr(34)
SevZip = Q2 & SevZip & Q2
    Ret = SH.Run(SevZip & " x " & Q2 & sFil & Q2 & " -aoa -o" & Q2 & Tempfol 
& Q2 & " * -r", 0, True)
Set SH = Nothing
WScript.quit

'------------------
From there the parent script processes the HXS content, builds
the files needed for a CHM, and then calls the Help Workshop
compiler to finish the job:

   Ret = SH.Run(Compiler & " " & Q2 & HHPPath & Q2, 0, True)

'  "C:\Program Files\HTML Help Workshop\hhc.exe" 
"C:\Windows\desktop\test2\temp1\script56.hhp"

  There is one catch in Vista+, though: If you
run in lackey mode, with file restrictions,
then there's no way to elevate with a drag/drop.
A console window can be started as admin. 

[toc] | [prev] | [next] | [standalone]

#11808

On Fri, 19 Jan 2018 23:20:01 -0500, Mayayana wrote:

>"Wally W." <ww84wa@aim.com> wrote
>
>| I often use wscript, but cscript can accept command line parameters.
>|
>| I often run cscript via a batch file.
>|
>| A batch file can also accept command line parameters, which may need
>| to be done via a shortcut.
>|
>| So: It is possible to drop a file onto a batch file (or its shortcut)
>| to process an input file with cscript.
>|
>| That way, there would be no need to respond on all the msgbox popups.
>|
>
>  I really don't get why anyone would want to go
>to all that trouble, but I guess it's a matter of
>personal taste. And maybe also a matter of what
>you're trying to accomplish. Most of what I do is
>to package some kind of functionality as a convenience
>for later. It's done if I can do the job next time
>without typing.
>
>  WScript can do plenty with command line, but
>I try to avoid it as much as I can.
>
>
>  Here's part of something I've been updating recently, to convert
>HXS files to CHM. The part below is, to me, some of the most
>tedious code, but it's necessary. I'm using 7-Zip to extract the
>file content of the HXS files. In brief, a folder of HXS is dropped
>onto the script, which creates a custom commandline to send
>to 7-Zip. It then calls a second script, zip7.vbs, and waits for
>the unpacking to finish by setting the 3rd parameter of
>WScript.Shell Run to True.
>  The second script does the same, after building a command
>line for 7-Zip out of the command string sent in, and calling
>7-Zip to do the unpacking. Then the main script continues,
>finishes the conversion, and starts again for the next file.
>
>  This allows me to unpack a folder full of HXS files and convert
>them all to CHM. The only msgbox is at the end, unless something
>goes wrong. It just pops up and tells me how many files it
>processed, to let me know it's done.
>
>  I could do this by using a number of calls in console.
>I could call 7-Zip with a command line. Then I could
>call a script to process the unpacked HXS. Then I could
>call the help compiler to build a CHM. But I still have to
>write all that code to actually do the work. So once I've
>done that, do I want to be able to just drop a folder
>onto a script, or do I want to type 3 long, tricky console
>lines for each HXS? Why would I do 99% of the work and
>then have to do all those tricky incantations every time
>I use it?
>
>  My approach is that if I expect to be doing the same thing
>repeatedly then it's worth reducing it as much as possible.
>If it can be reduced to a simple drag-drop that's best.
>If I had to open a console window that would mean I
>didn't write the script right. :)
>
>Below is the gist of what makes this particular utility work,
>showing it for a single HXS.
>
>sFil = WScript.Arguments(0)
>'-- sFil = "C:\Windows\desktop\test2\script56.hxs"
>' received from the dropped file.
>
>SevZip = "C:\Program Files\7-Zip\7z.exe"
>'-- path to 7-Zip
>
>'-- create a subfolder for unpacking the HXS.
>TempFol = "C:\Windows\desktop\test2\temp1"
>
>' Create a comand line to send to 7-Zip to get an HXS file unpacked.
>sCom = SevZip & "|" & sFil & "|" & TempFol
>
>' Get the path where this script is running
>ScrPath = WScript.ScriptFullName
>Pt4 = InStrRev(ScrPath, "\")
>
>' make the path to the second script to run 7-Zip
>ScrPath = Left(ScrPath, Pt4) & "zip7.vbs"
>
>' use WScript.Shell to send the command line to that script
>' and wait for it to return.
>SH.run Q2 & ScrPath & Q2 &  " " & Q2 & sCom & Q2, , True
>
>  '----- code in zip7.vbs that receives the command. ----
>' I don't actually remember why I made this external, but
>' it does make it work differently. By using Run to run a
>' second vbscript I do that work in a separate process.
>
>Arg = WScript.arguments(0)
>A3 = split(Arg, "|")
>SevZip = A3(0)
>sFil = A3(1)
>Tempfol = A3(2)
> On Error Resume Next
>Q2 = chr(34)
>SevZip = Q2 & SevZip & Q2
>    Ret = SH.Run(SevZip & " x " & Q2 & sFil & Q2 & " -aoa -o" & Q2 & Tempfol 
>& Q2 & " * -r", 0, True)
>Set SH = Nothing
>WScript.quit
>
>'------------------
>From there the parent script processes the HXS content, builds
>the files needed for a CHM, and then calls the Help Workshop
>compiler to finish the job:
>
>   Ret = SH.Run(Compiler & " " & Q2 & HHPPath & Q2, 0, True)
>
>'  "C:\Program Files\HTML Help Workshop\hhc.exe" 
>"C:\Windows\desktop\test2\temp1\script56.hhp"
>
>  There is one catch in Vista+, though: If you
>run in lackey mode, with file restrictions,
>then there's no way to elevate with a drag/drop.
>A console window can be started as admin. 
>

It isn't necessarily an either-or choice.

Cscript might have been useful in your diagnostics mode when you added
msgbox lines for your debugging effort.

Inserting wscript.echo statements in the start of your code above and
running it in cscript via a batch file lets me see all the results in
one go -- without all the annoying, extra clicking that is required
when running it in wscript.

I added a gratuitous msgbox statement to show they still work even in
cscript. It interrupts the flow of information in the console screen,
but is otherwise harmless to a diagnostics effort.

I placed two files in the root of my ramdisk:

==========
test.vbs
--------
sFil = WScript.Arguments(0)
'-- sFil = "C:\Windows\desktop\test2\script56.hxs"
' received from the dropped file.

wscript.echo "File name from drag and drop: " & sFil

SevZip = "C:\Program Files\7-Zip\7z.exe"
'-- path to 7-Zip

msgbox "But I really need a msgbox popup here."

'-- create a subfolder for unpacking the HXS.
TempFol = "C:\Windows\desktop\test2\temp1"

' Create a comand line to send to 7-Zip to get an HXS file unpacked.
sCom = SevZip & "|" & sFil & "|" & TempFol

wscript.echo "Created command line: " & sCom

' Get the path where this script is running
ScrPath = WScript.ScriptFullName
Pt4 = InStrRev(ScrPath, "\")

' make the path to the second script to run 7-Zip
ScrPath = Left(ScrPath, Pt4) & "zip7.vbs"

wscript.echo "Path to run second script: " & ScrPath
==========

==========
test.vbs
--------
cscript test.vbs %1
pause
==========

Placing quotes around the %1 in the batch file were not helpful for
some reason.

In this case, no shortcut to the batch file was needed.

I dragged and dropped a file onto the batch file in a simulated
diagnostics effort.

The results from the wscript.echo statements are in one screen instead
of having to respond to three msgbox popups:
=========
Z:\>cscript test.vbs "Z:\Drag and drop this.txt"
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

File name from drag and drop: Z:\Drag and drop this.txt
Created command line: C:\Program Files\7-Zip\7z.exe|Z:\Drag and drop
this.txt|C:
\Windows\desktop\test2\temp1
Path to run second script: Z:\zip7.vbs

Z:\>pause
Press any key to continue . . .
=========

The console screen can be closed either by responding to the PAUSE
statement or clicking the close box.

I prefer giving only one response to the diagnostics effort instead of
three, and having all the diagnostic information available in a
simultaneous display.

If all is well, the 'wscript.echo' statements can be removed, and the
GUI program will behave as intended.

[toc] | [prev] | [next] | [standalone]

#11809

On Sat, 20 Jan 2018 10:33:00 -0500, Wally W. wrote:

Editing the text below because I copied and pasted "test.vbs" where
the batch file name is "test.bat".

This edit affects none of the contents in either file, or the results.

The header is only the name of the file containing the text below the
line of single dashes.

>On Fri, 19 Jan 2018 23:20:01 -0500, Mayayana wrote:
>
>>"Wally W." <ww84wa@aim.com> wrote
>>
>>| I often use wscript, but cscript can accept command line parameters.
>>|
>>| I often run cscript via a batch file.
>>|
>>| A batch file can also accept command line parameters, which may need
>>| to be done via a shortcut.
>>|
>>| So: It is possible to drop a file onto a batch file (or its shortcut)
>>| to process an input file with cscript.
>>|
>>| That way, there would be no need to respond on all the msgbox popups.
>>|
>>
>>  I really don't get why anyone would want to go
>>to all that trouble, but I guess it's a matter of
>>personal taste. And maybe also a matter of what
>>you're trying to accomplish. Most of what I do is
>>to package some kind of functionality as a convenience
>>for later. It's done if I can do the job next time
>>without typing.
>>
>>  WScript can do plenty with command line, but
>>I try to avoid it as much as I can.
>>
>>
>>  Here's part of something I've been updating recently, to convert
>>HXS files to CHM. The part below is, to me, some of the most
>>tedious code, but it's necessary. I'm using 7-Zip to extract the
>>file content of the HXS files. In brief, a folder of HXS is dropped
>>onto the script, which creates a custom commandline to send
>>to 7-Zip. It then calls a second script, zip7.vbs, and waits for
>>the unpacking to finish by setting the 3rd parameter of
>>WScript.Shell Run to True.
>>  The second script does the same, after building a command
>>line for 7-Zip out of the command string sent in, and calling
>>7-Zip to do the unpacking. Then the main script continues,
>>finishes the conversion, and starts again for the next file.
>>
>>  This allows me to unpack a folder full of HXS files and convert
>>them all to CHM. The only msgbox is at the end, unless something
>>goes wrong. It just pops up and tells me how many files it
>>processed, to let me know it's done.
>>
>>  I could do this by using a number of calls in console.
>>I could call 7-Zip with a command line. Then I could
>>call a script to process the unpacked HXS. Then I could
>>call the help compiler to build a CHM. But I still have to
>>write all that code to actually do the work. So once I've
>>done that, do I want to be able to just drop a folder
>>onto a script, or do I want to type 3 long, tricky console
>>lines for each HXS? Why would I do 99% of the work and
>>then have to do all those tricky incantations every time
>>I use it?
>>
>>  My approach is that if I expect to be doing the same thing
>>repeatedly then it's worth reducing it as much as possible.
>>If it can be reduced to a simple drag-drop that's best.
>>If I had to open a console window that would mean I
>>didn't write the script right. :)
>>
>>Below is the gist of what makes this particular utility work,
>>showing it for a single HXS.
>>
>>sFil = WScript.Arguments(0)
>>'-- sFil = "C:\Windows\desktop\test2\script56.hxs"
>>' received from the dropped file.
>>
>>SevZip = "C:\Program Files\7-Zip\7z.exe"
>>'-- path to 7-Zip
>>
>>'-- create a subfolder for unpacking the HXS.
>>TempFol = "C:\Windows\desktop\test2\temp1"
>>
>>' Create a comand line to send to 7-Zip to get an HXS file unpacked.
>>sCom = SevZip & "|" & sFil & "|" & TempFol
>>
>>' Get the path where this script is running
>>ScrPath = WScript.ScriptFullName
>>Pt4 = InStrRev(ScrPath, "\")
>>
>>' make the path to the second script to run 7-Zip
>>ScrPath = Left(ScrPath, Pt4) & "zip7.vbs"
>>
>>' use WScript.Shell to send the command line to that script
>>' and wait for it to return.
>>SH.run Q2 & ScrPath & Q2 &  " " & Q2 & sCom & Q2, , True
>>
>>  '----- code in zip7.vbs that receives the command. ----
>>' I don't actually remember why I made this external, but
>>' it does make it work differently. By using Run to run a
>>' second vbscript I do that work in a separate process.
>>
>>Arg = WScript.arguments(0)
>>A3 = split(Arg, "|")
>>SevZip = A3(0)
>>sFil = A3(1)
>>Tempfol = A3(2)
>> On Error Resume Next
>>Q2 = chr(34)
>>SevZip = Q2 & SevZip & Q2
>>    Ret = SH.Run(SevZip & " x " & Q2 & sFil & Q2 & " -aoa -o" & Q2 & Tempfol 
>>& Q2 & " * -r", 0, True)
>>Set SH = Nothing
>>WScript.quit
>>
>>'------------------
>>From there the parent script processes the HXS content, builds
>>the files needed for a CHM, and then calls the Help Workshop
>>compiler to finish the job:
>>
>>   Ret = SH.Run(Compiler & " " & Q2 & HHPPath & Q2, 0, True)
>>
>>'  "C:\Program Files\HTML Help Workshop\hhc.exe" 
>>"C:\Windows\desktop\test2\temp1\script56.hhp"
>>
>>  There is one catch in Vista+, though: If you
>>run in lackey mode, with file restrictions,
>>then there's no way to elevate with a drag/drop.
>>A console window can be started as admin. 
>>
>
>It isn't necessarily an either-or choice.
>
>Cscript might have been useful in your diagnostics mode when you added
>msgbox lines for your debugging effort.
>
>Inserting wscript.echo statements in the start of your code above and
>running it in cscript via a batch file lets me see all the results in
>one go -- without all the annoying, extra clicking that is required
>when running it in wscript.
>
>I added a gratuitous msgbox statement to show they still work even in
>cscript. It interrupts the flow of information in the console screen,
>but is otherwise harmless to a diagnostics effort.
>
>I placed two files in the root of my ramdisk:
>
>==========
>test.vbs
>--------
>sFil = WScript.Arguments(0)
>'-- sFil = "C:\Windows\desktop\test2\script56.hxs"
>' received from the dropped file.
>
>wscript.echo "File name from drag and drop: " & sFil
>
>SevZip = "C:\Program Files\7-Zip\7z.exe"
>'-- path to 7-Zip
>
>msgbox "But I really need a msgbox popup here."
>
>'-- create a subfolder for unpacking the HXS.
>TempFol = "C:\Windows\desktop\test2\temp1"
>
>' Create a comand line to send to 7-Zip to get an HXS file unpacked.
>sCom = SevZip & "|" & sFil & "|" & TempFol
>
>wscript.echo "Created command line: " & sCom
>
>' Get the path where this script is running
>ScrPath = WScript.ScriptFullName
>Pt4 = InStrRev(ScrPath, "\")
>
>' make the path to the second script to run 7-Zip
>ScrPath = Left(ScrPath, Pt4) & "zip7.vbs"
>
>wscript.echo "Path to run second script: " & ScrPath
>==========
>

Editing the copy-and-paste error below where the file name (that is
not part of the file contents) should have been "test.bat"

>==========
>test.bat
>--------
>cscript test.vbs %1
>pause
>==========
>
>Placing quotes around the %1 in the batch file were not helpful for
>some reason.
>
>In this case, no shortcut to the batch file was needed.
>
>I dragged and dropped a file onto the batch file in a simulated
>diagnostics effort.
>
>The results from the wscript.echo statements are in one screen instead
>of having to respond to three msgbox popups:
>=========
>Z:\>cscript test.vbs "Z:\Drag and drop this.txt"
>Microsoft (R) Windows Script Host Version 5.8
>Copyright (C) Microsoft Corporation. All rights reserved.
>
>File name from drag and drop: Z:\Drag and drop this.txt
>Created command line: C:\Program Files\7-Zip\7z.exe|Z:\Drag and drop
>this.txt|C:
>\Windows\desktop\test2\temp1
>Path to run second script: Z:\zip7.vbs
>
>Z:\>pause
>Press any key to continue . . .
>=========
>
>The console screen can be closed either by responding to the PAUSE
>statement or clicking the close box.
>
>I prefer giving only one response to the diagnostics effort instead of
>three, and having all the diagnostic information available in a
>simultaneous display.
>
>If all is well, the 'wscript.echo' statements can be removed, and the
>GUI program will behave as intended.

[toc] | [prev] | [next] | [standalone]

#11810

"Wally W." <ww84wa@aim.com> wrote

| It isn't necessarily an either-or choice.
|
| Cscript might have been useful in your diagnostics mode when you added
| msgbox lines for your debugging effort.
|

   It's hard to see how. And I don't need any of
the messages you added. I only need a message
if it doesn't work. Also, you're just talking about
testing. The whole thing is still designed as a
wscript operation: Drag/drop and wait for the
"Done." message. In other words, you're not
writing a console version. You're just running the
script via console.

  While I dislike console I'm also rather curious
about why people like it, aside from familiarity.
It obviously works for you but I honestly can't
think of anything I'd want cscript for.

   The other day I ran UPX in console, all the
while snarling that the authors can't be bothered
to finish the product by making a UI. A few years
ago I had to use console to swap out the hal.dll
file when I got a dual CPU. In between I've maybe
used it a couple of times for things I don't
remember. I use it if there's no choice. If I used
UPX on a regular basis I'd write a drag/drop
wrapper for it, like the UPX author should have
done a long time ago.

 Having to click a msgbox to dismiss it when debugging
is not something that gets on my nerves.... unless
it's in a long loop and I forgot to kill the msgbox
after the first loop. :) Sometimes that happens and
I have to kill wscript. But in general, running the test
is not what takes time.

| I prefer giving only one response to the diagnostics effort instead of
| three, and having all the diagnostic information available in a
| simultaneous display.
|
| If all is well, the 'wscript.echo' statements can be removed, and the
| GUI program will behave as intended.
|
   So you mainly use cscript for testing wscript
scripts? My example above was showing how it
was much easier to run command lines within my
script rather than typing in a window. Are there
actual tasks that you find easier in console? I
just can't think of any way it could be easier.

You can type something like:
cscript c:\script1.vbs c:\txt1.txt

....Or whatever one might do to pass txt1.txt to
script1.vbs as a commandline. But I can just drop
the file txt1.txt onto script1.vbs and I'm done. 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web