What should one read to learn VBScript?

Discussion:

(too old to reply)

Peter Percival

2018-01-17 12:55:36 UTC

Permalink

What should one read to learn VBScript? I am new to VBScript but an
experienced programmer.

Mayayana

2018-01-17 15:25:34 UTC

Permalink

"Peter Percival" <***@hotmail.com> wrote

| What should one read to learn VBScript? I am new to VBScript but an
| experienced programmer.

That's a big topic. In part it depends on what
you want to do. Are you aware that VBS is officially
"deprecated"? Microsoft is pushing PowerShell and
command line, to the extent they're pushing anything.

VBS is extremely useful and flexible, nonetheless, and
the Windows Script Host that makes it usable is still
part of all Windows versions. I use it almost daily to
automate tasks.

There's VBS and Windows Script Host (WSH). They overlap.
VBS can be used in IE for dynamic webpage scripting,
and in HTAs. The early VBS books were actually just Web
scripting books. But then MS added COM support
(ActiveX objects) and VBS became a general programming
tool. With WSH, circa Win98, they were introducing a
new replacement for BAT files to go with the GUI era.
(Ironically, PowerShell is a step backward to command line,
aimed at making Linux server admins feel at home on
Windows while "civilian" Windows users are discouraged
from trying to do anything handy.)

The VBS language is relatively simple, but the tools are
vast. Connecting to any COM object brings a unique
set of available functions. docs for such things are not
part of VBS docs.

I have a couple of Wrox books that are good. O'Reilly
books are generally OK. But the single most useful
thing to my mind is the help files. There's a file called
script56.chm. I don't know if you can still find it.
Microsoft have made a mess of Windows docs. Each
topic used to come with its own SDK: scripting,
AA, Windows Installer, etc. Now they're all packed
into one gigantic SDK, with help docs in HXS format.
HXS, in turn, requires a reader. They deliberately
broke CHM format with HXS. On the bright side, an
HXS can be converted to a CHM:

---------------------------------------------
Instructions for getting CHM files:
---------------------------------------------

Go here and download the win7 SDK:

https://www.microsoft.com/en-us/download/confirmation.aspx?id=18950

(Don't download the web installer nonsense. It should
be an ISO about 1.5 GB.)

Open the ISO in 7-Zip and take out the Setup folder.
In there, find these files and extract them from the CABs:

WinSDKDocWin32\cab2.cab -> WinSDK_script56....

Reference for windows Script Host. It includes VBS
methods as well as documentation of common objects
like FileSystemObject.
Note that FSO, WScript.Shell, etc are basic objects
that are considered to be part of WSH and are therefore
detailed in the help file. But any COM object offering a
dispatch/dual interface can be used by VBS. And you
can write those yourself.

WinSDKDocWin32\cab5.cab -> WinSDK_shell...

Reference for Shell.Application, which provides
access to various functions, including Explorer.
IE and Explorer are technically the same, left over
from Active Desktop. As a result, VBS can access
Explorer windows.

WinSDKDocWin32\cab5.cab -> WinSDK_DHTML...

Full IE scripting reference. Last topic deals with
the entire IE DOM for webpage scripting.

Then go here and download my converter utility.
(Written as an HTA using VBScript. :)
www.jsware.net/jsware/hxs2chm.php5

There are instructions to convert the whole SDK
doc mess into CHMs. Or you can just extract the
relevant files (above), rename them to .hxs files,
then use the HTA to convert them one at a time.

You *can* install the SDK if you want to, but it's
gigantic. Most of it probably won't be of interest.
And then you're stuck going through the SDK to
read the help files.

-----------------------------------------------

I also have a webpage here:

www.jsware.net/jsware/scripts.php5

There's some info, lots of samples that start out
simple, and numerous components that are free to
use.

If you need more help you might want to come back
with specific details about what you're trying to do.

Mayayana

2018-01-18 02:50:14 UTC

Permalink

"Mayayana" <***@invalid.nospam> wrote

| Then go here and download my converter utility.
| (Written as an HTA using VBScript. :)
| www.jsware.net/jsware/hxs2chm.php5
|

An update about the HXS conversion utility:

I tested it out today to make sure of the details
of where to get the SDK, etc. In the process I
found that at least one HXS in the Win7 SDK
was faulty and it happened to be the scripting
help file.

It's the first I've seen of this. The index file inside
the HXS is faulty, with wrong data. I've just rewritten
the tools to deal with it. If anyone tried to convert
script56 and failed, try the new version.

This is actually not so surprising. Micorosft have
an odd habit of just breaking stuff for no apparent
reason. I once had to rewrite my MSI unpacker
utilities when I came across a faulty MSI file from
MS themselves. They had managed to screw it
up in a way I hadn't foreseen as possible. :)

Wally W.

2018-01-18 03:49:54 UTC

Permalink

Boo!

Can't they stick with anything?

I have been saying for years that I am moving to Linux. Windows 10
looks like it is going to be the motivation to make it happen. My
experience with a Windows 10 machine that wants to hog my internet
connection for ginormous updates seems to be the last straw.

Post by Mayayana
Microsoft is pushing PowerShell and
command line, to the extent they're pushing anything.
VBS is extremely useful and flexible, nonetheless, and
the Windows Script Host that makes it usable is still
part of all Windows versions. I use it almost daily to
automate tasks.
There's VBS and Windows Script Host (WSH). They overlap.
VBS can be used in IE for dynamic webpage scripting,
and in HTAs. The early VBS books were actually just Web
scripting books. But then MS added COM support
(ActiveX objects) and VBS became a general programming
tool. With WSH, circa Win98, they were introducing a
new replacement for BAT files to go with the GUI era.
(Ironically, PowerShell is a step backward to command line,
aimed at making Linux server admins feel at home on
Windows while "civilian" Windows users are discouraged
from trying to do anything handy.)
The VBS language is relatively simple, but the tools are
vast. Connecting to any COM object brings a unique
set of available functions. docs for such things are not
part of VBS docs.
I have a couple of Wrox books that are good. O'Reilly
books are generally OK. But the single most useful
thing to my mind is the help files. There's a file called
script56.chm. I don't know if you can still find it.
Microsoft have made a mess of Windows docs. Each
topic used to come with its own SDK: scripting,
AA, Windows Installer, etc. Now they're all packed
into one gigantic SDK, with help docs in HXS format.
HXS, in turn, requires a reader. They deliberately
broke CHM format with HXS. On the bright side, an
---------------------------------------------
---------------------------------------------
https://www.microsoft.com/en-us/download/confirmation.aspx?id=18950
(Don't download the web installer nonsense. It should
be an ISO about 1.5 GB.)
Open the ISO in 7-Zip and take out the Setup folder.
WinSDKDocWin32\cab2.cab -> WinSDK_script56....
Reference for windows Script Host. It includes VBS
methods as well as documentation of common objects
like FileSystemObject.
Note that FSO, WScript.Shell, etc are basic objects
that are considered to be part of WSH and are therefore
detailed in the help file. But any COM object offering a
dispatch/dual interface can be used by VBS. And you
can write those yourself.
WinSDKDocWin32\cab5.cab -> WinSDK_shell...
Reference for Shell.Application, which provides
access to various functions, including Explorer.
IE and Explorer are technically the same, left over
from Active Desktop. As a result, VBS can access
Explorer windows.
WinSDKDocWin32\cab5.cab -> WinSDK_DHTML...
Full IE scripting reference. Last topic deals with
the entire IE DOM for webpage scripting.
Then go here and download my converter utility.
(Written as an HTA using VBScript. :)
www.jsware.net/jsware/hxs2chm.php5
There are instructions to convert the whole SDK
doc mess into CHMs. Or you can just extract the
relevant files (above), rename them to .hxs files,
then use the HTA to convert them one at a time.
You *can* install the SDK if you want to, but it's
gigantic. Most of it probably won't be of interest.
And then you're stuck going through the SDK to
read the help files.
-----------------------------------------------
www.jsware.net/jsware/scripts.php5
There's some info, lots of samples that start out
simple, and numerous components that are free to
use.
If you need more help you might want to come back
with specific details about what you're trying to do.

Peter Percival

2018-01-18 12:42:31 UTC

Permalink

Post by Mayayana
| What should one read to learn VBScript? I am new to VBScript but an
| experienced programmer.
That's a big topic. In part it depends on what
you want to do. Are you aware that VBS is officially
"deprecated"? Microsoft is pushing PowerShell and
command line, to the extent they're pushing anything.
VBS is extremely useful and flexible, nonetheless, and
the Windows Script Host that makes it usable is still
part of all Windows versions. I use it almost daily to
automate tasks.

Thanks for the reply and the links below. They are genuinely helpful!

Post by Mayayana
There's VBS and Windows Script Host (WSH). They overlap.
VBS can be used in IE for dynamic webpage scripting,
and in HTAs. The early VBS books were actually just Web
scripting books. But then MS added COM support
(ActiveX objects) and VBS became a general programming
tool. With WSH, circa Win98, they were introducing a
new replacement for BAT files to go with the GUI era.
(Ironically, PowerShell is a step backward to command line,
aimed at making Linux server admins feel at home on
Windows while "civilian" Windows users are discouraged
from trying to do anything handy.)
The VBS language is relatively simple, but the tools are
vast. Connecting to any COM object brings a unique
set of available functions. docs for such things are not
part of VBS docs.
I have a couple of Wrox books that are good. O'Reilly
books are generally OK. But the single most useful
thing to my mind is the help files. There's a file called
script56.chm. I don't know if you can still find it.
Microsoft have made a mess of Windows docs. Each
topic used to come with its own SDK: scripting,
AA, Windows Installer, etc. Now they're all packed
into one gigantic SDK, with help docs in HXS format.
HXS, in turn, requires a reader. They deliberately
broke CHM format with HXS. On the bright side, an
---------------------------------------------
---------------------------------------------
https://www.microsoft.com/en-us/download/confirmation.aspx?id=18950
(Don't download the web installer nonsense. It should
be an ISO about 1.5 GB.)
Open the ISO in 7-Zip and take out the Setup folder.
WinSDKDocWin32\cab2.cab -> WinSDK_script56....
Reference for windows Script Host. It includes VBS
methods as well as documentation of common objects
like FileSystemObject.
Note that FSO, WScript.Shell, etc are basic objects
that are considered to be part of WSH and are therefore
detailed in the help file. But any COM object offering a
dispatch/dual interface can be used by VBS. And you
can write those yourself.
WinSDKDocWin32\cab5.cab -> WinSDK_shell...
Reference for Shell.Application, which provides
access to various functions, including Explorer.
IE and Explorer are technically the same, left over
from Active Desktop. As a result, VBS can access
Explorer windows.
WinSDKDocWin32\cab5.cab -> WinSDK_DHTML...
Full IE scripting reference. Last topic deals with
the entire IE DOM for webpage scripting.
Then go here and download my converter utility.
(Written as an HTA using VBScript. :)
www.jsware.net/jsware/hxs2chm.php5
There are instructions to convert the whole SDK
doc mess into CHMs. Or you can just extract the
relevant files (above), rename them to .hxs files,
then use the HTA to convert them one at a time.
You *can* install the SDK if you want to, but it's
gigantic. Most of it probably won't be of interest.
And then you're stuck going through the SDK to
read the help files.
-----------------------------------------------
www.jsware.net/jsware/scripts.php5
There's some info, lots of samples that start out
simple, and numerous components that are free to
use.
If you need more help you might want to come back
with specific details about what you're trying to do.

Peter Percival

2018-01-19 21:28:11 UTC

Permalink

Then my question becomes -

What should one read to learn about PowerShell? I am new to PowerShell
but an experienced programmer.

"I am new to" means I hadn't even heard of it until you mentioned it!

Peter Percival

2018-01-19 21:59:07 UTC

Permalink

Post by Peter Percival

| What should one read to learn VBScript? I am new to VBScript but an
| experienced programmer.
That's a big topic. In part it depends on what
you want to do. Are you aware that VBS is officially
"deprecated"? Microsoft is pushing PowerShell and
command line, to the extent they're pushing anything.

Then my question becomes -
What should one read to learn about PowerShell? I am new to PowerShell
but an experienced programmer.
"I am new to" means I hadn't even heard of it until you mentioned it!

I've just come across

Microsoft PowerShell, VBScript & JScript Bible
by William R. Stanek, James O'Neill, Jeffrey Rosen

any thoughts?

Mayayana

2018-01-19 23:06:17 UTC

Permalink

"Peter Percival" <***@hotmail.com> wrote

| I've just come across
|
| Microsoft PowerShell, VBScript & JScript Bible
| by William R. Stanek, James O'Neill, Jeffrey Rosen
|
| any thoughts?

You *still* haven't given any clue about what
you want it for. How can anyone advise you?

For PS you might ask here, though it doesn't look
very busy:

microsoft.public.windows.powershell

I don't know that book. In my experience, pretty
much all books are for beginners and may be somewhat
helpful to get started, but then you just need reference.

I have an aversion to "Bible" books. The Windows
Bible books were very expensive and almost useless
in my view. But that may not mean anything.

Windows Script Host by Dino Esposito is pithy, but
not if you're just an admin. On the other hand, if
what you want is admin books that's mostly what
you'll find with scripting and PS because that's the
biggest market.

I actually first learned about VBS from a book called
Windows 98 Annoyances. It was a wonderful tweaking
guide and near the end he explained the basics of VBS
and where it fit into Windows. At the time I had no
programming experience at all. I was fairly new to
computers. But the author, David Karp, introduced
me to the idea that I could control things from the
other side of the computer screen and I was hooked.

Peter Percival

2018-01-20 14:15:32 UTC

Permalink

Post by Mayayana
| I've just come across
|
| Microsoft PowerShell, VBScript & JScript Bible
| by William R. Stanek, James O'Neill, Jeffrey Rosen
|
| any thoughts?
You *still* haven't given any clue about what
you want it for.

Just-for-fun programming. Firtling/furtling about under the hood, so to
speak. No doubt I can firtle/furtle to my heart's content using C, but
my guess (note "guess") is that using a scripting language will be
quicker. And it will provide an opportunity to learn something new.

Post by Mayayana
How can anyone advise you?
For PS you might ask here, though it doesn't look
microsoft.public.windows.powershell
I don't know that book. In my experience, pretty
much all books are for beginners and may be somewhat
helpful to get started, but then you just need reference.
I have an aversion to "Bible" books. The Windows
Bible books were very expensive and almost useless
in my view. But that may not mean anything.
Windows Script Host by Dino Esposito is pithy, but
not if you're just an admin. On the other hand, if
what you want is admin books that's mostly what
you'll find with scripting and PS because that's the
biggest market.
I actually first learned about VBS from a book called
Windows 98 Annoyances. It was a wonderful tweaking
guide and near the end he explained the basics of VBS
and where it fit into Windows. At the time I had no
programming experience at all. I was fairly new to
computers. But the author, David Karp, introduced
me to the idea that I could control things from the
other side of the computer screen and I was hooked.

Mayayana

2018-01-19 22:06:20 UTC

Permalink

"Peter Percival" <***@hotmail.com> wrote

| What should one read to learn about PowerShell? I am new to PowerShell
| but an experienced programmer.
|

Maybe someone else can answer that. Or there
may be a PS group. As far as I'm concerned, life's
too short for command line.

PowerShell was designed to appeal to Linux people
who are used to working in console windows with
commands that are standalone applets. But in this
case the applets are actually .Net programs. So
.Net is a requisite.

Imagine commandline Java. If that sounds
like fun then maybe you want Powershell. But
as a system of commandline applets it's really
all about learning the commands rather than
programming.

Like WSH and WMI before it, PS is mainly aimed
at admins. WMI turned out to be a vast system
with very little value. WSH turned out to be a
high-level programming system due to COM
integration. PowerShell? It might be what you need,
but you never did say anything about what you
want to accomplish. If you want to get an admin
IT job then definitely you want PS. Otherwise?

Here's an example that might give you an idea
of how it works. It's a discussion about searching for
a word in a number of files.

https://stackoverflow.com/questions/8153750/how-to-search-a-string-in-multiple-files-and-return-the-names-of-files-in-powers

In VBScript that would be done in a way that's
vaguely similar to the API: Get a folder object.
Get the folder files as a collection. For Each
through the files, opening them, searching the
content as a string, creating a report to write
to disk or show as a message.... that kind of thing.

In PS it's more like DOS with endless switches
and an unlimited possible number of commands.

Peter Percival

2018-01-20 14:20:00 UTC

Permalink

Post by Mayayana
| What should one read to learn about PowerShell? I am new to PowerShell
| but an experienced programmer.
|
Maybe someone else can answer that. Or there
may be a PS group. As far as I'm concerned, life's
too short for command line.
PowerShell was designed to appeal to Linux people
who are used to working in console windows with
commands that are standalone applets. But in this
case the applets are actually .Net programs. So
.Net is a requisite.
Imagine commandline Java. If that sounds
like fun then maybe you want Powershell. But
as a system of commandline applets it's really
all about learning the commands rather than
programming.
Like WSH and WMI before it, PS is mainly aimed
at admins. WMI turned out to be a vast system
with very little value. WSH turned out to be a
high-level programming system due to COM
integration. PowerShell? It might be what you need,
but you never did say anything about what you
want to accomplish. If you want to get an admin
IT job then definitely you want PS. Otherwise?
Here's an example that might give you an idea
of how it works. It's a discussion about searching for
a word in a number of files.
https://stackoverflow.com/questions/8153750/how-to-search-a-string-in-multiple-files-and-return-the-names-of-files-in-powers

Thank you. It so happens that one thing I want to write is a find
utility that is better than the "Type here to search" box in the lower
left-hand corner of my screen. (Most anything is going to be better.)
So that will be genuinely useful.

Post by Mayayana
In VBScript that would be done in a way that's
vaguely similar to the API: Get a folder object.
Get the folder files as a collection. For Each
through the files, opening them, searching the
content as a string, creating a report to write
to disk or show as a message.... that kind of thing.
In PS it's more like DOS with endless switches
and an unlimited possible number of commands.

Mayayana

2018-01-20 14:40:32 UTC

Permalink

"Peter Percival" <***@hotmail.com> wrote

| >
https://stackoverflow.com/questions/8153750/how-to-search-a-string-in-multiple-files-and-return-the-names-of-files-in-powers
|
| Thank you. It so happens that one thing I want to write is a find
| utility that is better than the "Type here to search" box in the lower
| left-hand corner of my screen. (Most anything is going to be better.)

I should think so! Do you know Agent Ransack?
It might be worth a look. I haven't used Windows
search for years. And doesn't it call home now on
Win10?

If you use C you can probably figure out the
landscape here for yourself. For what it's worth:

* You might like javascript better than VBS, insofar
as it's designed to look like C/C++. It has almost
the same functionality in Windows Script Host (WSH).

* WSH can also accomodate installing other languages,
in case you're one of those Perl weirdos. :)

* PowerShell is vast. If you prefer commandline
you should be able to do what you like with that.

* One big difference that's probably worth noting
is that the power of VBS/JS in WSH mainly comes from
COM. Just about any dispatch/dual interface can be
used. And GUI programs can be written with script
and HTML as an HTA. PS, by contrast, seems to
get its power from .Net, with the ability to access
the .Net object model. But I'm somewhat speculating
there. I really don't know much about PS.

* If you look at my scripts page, linked above, the
left side of the index is scripts and the right side
is components that can be used in script. What's
there is probably a good general listing of the kinds
of things you can do with WSH.

I use it to make tools, like the HXStoCHM
converter, and to do little things. I have lots of
VBS scripts on my desktop, to clean up URLs,
fix returns in text files, decode base64, remove
read-only attributes, etc.

An interesting example: Last night I wrote a script
to make a readable webpage from something I
downloaded.

http://www.uceprotect.net/en/index.php?m=7&s=6

I went to the US Congress site to find out whether
any congresspeople I vote for had voted to extend
the FISA spying and warrantless wiretapping law.
(I'm amazed that a majority still support a probably
illegal law that was originally passed shortly after 9/11.)

What I got was a page with limited info. But it turned
out that all of the info was actually in the source code.
There was a line for every house rep:

<recorded-vote><legislator name-id="A000374" sort-field="Abraham"
unaccented-name="Abraham" party="R" state="LA"
role="legislator">Abraham</legislator><vote>Yea</vote></recorded-vote>

I realized it would be easy to write a script to parse
that mess and generate a webpage with a color-coded
listing by party and vote. I wrote the code below, added
the CSS at the top of the XML file, then dropped the XML
file onto the script to generate a readable webpage. That
script may stay on my desktop in case I want to read
future rollcall votes.

'----------------------------------------------
Dim FSO, TS, s1, s2, Arg, A1, i2, Q2

Q2 = Chr(34)
Arg = WScript.Arguments(0)
Set FSO = CreateObject("Scripting.FileSystemObject")

Set TS = FSO.OpenTextFile(Arg, 1)
s1 = TS.ReadAll
TS.Close
Set TS = Nothing

A1 = Split(s1, vbCrLf)
For i2 = 0 to UBound(A1)
s2 = A1(i2)
If Left(s2, 15) = "<recorded-vote>" Then
ParseS2 s2
A1(i2) = s2
End If
Next

s1 = Join(A1, vbCrLf)
Set TS = FSO.CreateTextFile(Arg & "2", True)
TS.Write s1
TS.Close
Set TS = Nothing
Set FSO = Nothing

Sub ParseS2(sIn)
Dim Pt1, Pt2, sName, sParty, sVote, sState

Pt1 = InStr(sIn, "field=")
Pt2 = InStr((Pt1 + 7), sIn, Q2)
sName = Mid(sIn, Pt1 + 7, Pt2 - (Pt1 + 7))

Pt1 = InStr(sIn, "party=")
Pt2 = InStr((Pt1 + 7), sIn, Q2)
sParty = Mid(sIn, Pt1 + 7, Pt2 - (Pt1 + 7))

Pt1 = InStr(sIn, "state=")
Pt2 = InStr((Pt1 + 7), sIn, Q2)
sState = Mid(sIn, Pt1 + 7, Pt2 - (Pt1 + 7))

Pt1 = InStr(sIn, "<vote>")
Pt2 = InStr((Pt1 + 6), sIn, Q2)
sVote = Mid(sIn, Pt1 + 6, 1)

If sParty = "R" Then
sIn = "" & sName & " (" & sState &
") "
Else
sIn = "" & sName & " (" & sState &
") "
End If
If sVote = "Y" Then
sIn = sIn & "    Y
 "
Else
sIn = sIn & "     N
 "
End If
End Sub

Wally W.

2018-01-19 22:20:03 UTC

Permalink

Post by Peter Percival

Then my question becomes -
What should one read to learn about PowerShell? I am new to PowerShell
but an experienced programmer.
"I am new to" means I hadn't even heard of it until you mentioned it!

Likewise.

And sysadmins want it that way.

Cross-platform is good, because it sounds like the scripts can be used
in Linux.

But Powershell looks like it sucks for things that need to be portable
in the Apple_control_freak--wannabe world of Windows:

https://www.pdq.com/blog/powershell-how-to-write-your-first-powershell-script/
Go ahead and try that command. You **should** [really?!!!] get an
error that says scripts have been disabled on your system.
...
This is normal behavior. [in the world of M$ and their drones]

There are 4 execution policies you can use:
Restricted Scripts wont run. Period. (Default setting)
...
In order to change the execution policy, we will need to reopen
PowerShell as an Administrator (the command will fail otherwise)

IOW: Probably not a useful language unless one has admin rights on
what is still called (in newspeak), a **personal** computer.

Mayayana

2018-01-19 22:52:52 UTC

Permalink

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

|
https://www.pdq.com/blog/powershell-how-to-write-your-first-powershell-script/
| Go ahead and try that command. You **should** [really?!!!] get an
| error that says scripts have been disabled on your system.
| ...
| This is normal behavior. [in the world of M$ and their drones]
|
Interesting. I didn't know that. I mainly work on
XP and don't even have PS installed. It's optional
on XP and I see no reason to add the security risk.

Sohel Alam

2018-05-15 00:19:55 UTC

Permalink

You are a mythical God of operating system.

Wally W.

2018-01-18 03:44:48 UTC

Permalink

Post by Peter Percival
What should one read to learn VBScript? I am new to VBScript but an
experienced programmer.

No recommendations on one thing to read, but it should be relatively
easy for an experienced programmer to pick up.

It is quite BASIC-ish, but needs to use object-oriented pieces to
reach into Windows for values.

I have come to be able to do things that are useful to me by starting
to build a BASIC-ish program and then ask Google when I need to access
a particular feature.

Or I search for programs that are close to what I want to do and tweak
them for my preferences.

I usually find what I need at msdn.microsoft.com or stackoverflow.com.

There are two flavors:
wscript (Windows GUI script)
cscript (console script)

I recommend starting with cscript because reacting to the error
reporting is less tedious.

This Google search seems to return some interesting possibilities for
places to start: vbs tutorial cscript

Peter Percival

2018-01-18 12:40:13 UTC

Permalink

Post by Wally W.

Post by Peter Percival
What should one read to learn VBScript? I am new to VBScript but an
experienced programmer.

That's my preferred plan of action!

Post by Wally W.
I usually find what I need at msdn.microsoft.com or stackoverflow.com.
wscript (Windows GUI script)
cscript (console script)
I recommend starting with cscript because reacting to the error
reporting is less tedious.
This Google search seems to return some interesting possibilities for
places to start: vbs tutorial cscript

Mayayana

2018-01-18 14:27:48 UTC

Permalink

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

| I recommend starting with cscript because reacting to the error
| reporting is less tedious.
|

Some people prefer command line, but you
sacrifice the complexity and convenience
of GUI by doing that. And of course you
lose the advantages of GUI itself, like HTAs.

Just yesterday I was
updating my HXStoCHM utility to accomodate
MS bugs. I had a hard time with one part.
Putting a number of msgbox lines in the code
allowed me to track it down. I can't imagine how
I would have done that running command line.
It just would have meant typing out long
command lines instead of dropping one file
onto another.

Special Access

2018-01-19 02:57:30 UTC

Permalink

On Thu, 18 Jan 2018 09:27:48 -0500, "Mayayana"

Post by Mayayana
| I recommend starting with cscript because reacting to the error
| reporting is less tedious.
|
Some people prefer command line, but you
sacrifice the complexity and convenience
of GUI by doing that. And of course you
lose the advantages of GUI itself, like HTAs.
Just yesterday I was
updating my HXStoCHM utility to accomodate
MS bugs. I had a hard time with one part.
Putting a number of msgbox lines in the code
allowed me to track it down. I can't imagine how
I would have done that running command line.
It just would have meant typing out long
command lines instead of dropping one file
onto another.

when I was working with VBS, I found this site:
http://www.vbsedit.com/

nice editor, even has a HTA editor as well. Was relatively
inexpensive for "shareware" program.

Mike

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Wally W.

2018-01-20 01:53:05 UTC

Permalink

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.

The text from wscript.echo statements (which behave as msgbox popups
in wscript) could be redirected to a text file.

Or the batch file can end with a PAUSE statement so the text doesn't
go away before you want it to.

So far, the sysadmins haven't taken away vbscript, but it's in their
must-piss-with-others DNA to do so eventually.

Mayayana

2018-01-20 04:20:01 UTC

Permalink

"Wally W." <***@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.

Wally W.

2018-01-20 15:33:00 UTC

Permalink

Post by Mayayana
| 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
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.

Wally W.

2018-01-20 15:44:26 UTC

Permalink

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.

Post by Wally W.

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

Post by Wally W.
==========
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
=========
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
\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.

Mayayana

2018-01-20 18:53:00 UTC

Permalink

"Wally W." <***@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.