[Ann] "vbNetAssembly.ProgressBarDialog1", a scripting utility...

[mr_unreliable]

Years ago, Alex K. Angelopoulos (mvps) suggested that vb.Net could be
used from script to supplement or make up for deficiencies in vbs.
Further, he explained how to use vb.Net from script, and provided some
"lite-weight" examples. See here:

http://www.mvps.org/scripting/dotnet/index.htm

Good Idea (maybe). To my way of thinking one of the major deficiencies
of vbs is the lack of a progressbar dialog in the language. The usual
recommendation found here is to make up a dialog from html/dhtml and
use Internet Explorer's automation interface to diaplay it. A.K.A.'s
notion of using vb.Net leads one to wonder -- could vb.Net be used as
a GUI, or more specifically a progressbar dialog -- from script? The
advantage being that vb.Net is a genuine microsoft product, not some
untrustworthy and unreliable third party control. A possible
secondary advantage might be that the vb.Net command line compiler
suggested by A.K.A. is a very fast compiler, leading to the possibility
of your dialog popping up faster than a dialog constructed using (ugh!,
gross!, bloated!) Internet Explorer...

The attached script is a demo of using the vb.Net command line compiler
(let's call it vbc) to create from vb.Net a Status-Message-Progress-Bar
dialog, wrapped up in a "com wrapper" and registered for use by script.
Further, the script contains everything you need, i.e., the source
files for vb.Net, plus the instructions for the compilation, plus the
registration, plus the demo. In this, it compares with a script that
contains "built-in" html/dhtml for constructing an IE dialog.

Result One: yes, you can use vb.Net instead of IE for dialogs from
script (even on my system-of-choice - win98). Result Two: while vbc
is a fast compiler, the process of setting up the source code, compiling
and registering the netAssembly takes time -- about as much as loading
IE. And, if you already have IE loaded (in memory) on your system,
it could take longer. (Note: on an older-and-slower system it takes
about five seconds to compile, on a newer system, with newer processors
running five-or-six times faster than mine, you may not even notice the
time lapse for compilation). Anyway, if your script only takes a couple
of seconds to run, no progressbar is necessary. A progbar dialog is
only really useful for graphically showing the progress of a script that
takes some time to complete.

Result Three: when all-is-said-and-done, I can't see any real difference
between coding up an actX com object using (classic) vb, and registering
it for use, as compared with coding up a netAssembly in vb.Net and
wrapping it into a com object and registering it for use -- except that
vb.Net is a microsoft product and therefore more acceptable to
professional scripters vs. the notion of using a 3rd-party control.

As for the script below, it is an all-in-one experience. It includes
the vb.Net source code and the coding needed to compile and register it
-- and also UN-register it. But one could split the script apart, and
run the compile and register part separately. Then you are left with
a com object in your registry that you could use indefinitely as a
progbar dialog. Note: if you _do_ happen to split the script, then
the com object will load immediately (as would an ocx), i.e., there
would be no compilation delay before showing the dialog.

And finally, the vb.Net code was developed on winXP using microsoft's
"Visual Basic 2005 Express Edition" (free - at least for now) compiler.
Then it was transferred via sneaker-net to win98 for testing and
debugging (with Net Framework v1.1.4322). Unfortunately, due to my
ignorance with xp, I could not get this script to work when I took it
back onto xp. You will have to trust that the _original_ code worked
with vb2005ee, but as for this script -- something went wrong. It
appeared that the script couldn't find the compiler _or_ the
"system.xx.dll's. Even though they were present in the net framework
directory (v2.0.50727). The net framework directory didn't appear in
the "path" enviornmemt, and my ignorance of xp was evident in that I
couldn't find the "path" defined in autoexec.bat (as in win98) and so
I got lost...

Anyway for you win98 folks, have fun...

cheers, jw

[mr_unreliable]

uh-oh. Kindly remove line 4 of the script (this one):

<object id="oDBDlg" progid="wshAPIToolkit.ucDBDialog"....

cheers, jw

[mr_unreliable]

uh-oh. Some of the posted code looks really ugly, because of the
different "tab" settings between the various code editors and my
newsreader.

Down with tabs...

sorry, jw

[mr_unreliable]

First, you have to make sure that the Net Framework is in your path.
I had expected microsoft "visual basic 2005 express edition" to do
this for me auto-magically, but apparently not. So add this to
your xp path:

%SystemRoot%\Microsoft.NET\Framework\v2.0.50727

or, whatever your version of net framework happens to be.

Secondly, kindly change (the original) line 831 of the posted
"wshDemo_vbNetAssembly_asGUI.wsf" script from this:

/reference:Microsoft.VisualBasic.dll,System.dll,System.Data.dll,System.Drawing.dll,System.Windows.Forms.dll,System.XML.dll"

to this:

/reference:Microsoft.VisualBasic.dll,System.dll,System.Data.dll,System.Drawing.dll,System.Windows.Forms.dll,System.XML.dll

In other words, kindly remove the redundant double-quote mark at
the end of that line. For some unknown reason, net framework v1.1
tolerated that, but net framework 2.0 threw an error.

that's all folks, jw