More Windows Scripting Workarounds from Nilpo

Scripting, by nature, is a limited form of programming. As a result of these limitations it is sometimes necessary to employ workarounds in order to produce a desired effect. I showed you some of the workarounds that I commonly use in the first volume of this series. Today, I return with volume two to demonstrate more workarounds that you may find useful in your scripting endeavors.

While I have discovered many of these workarounds on my own, some of them are not my own creation.  Some of these can be found on the Rube Goldberg Memorial Scripting Page.  I apologize for others in this series that may go uncredited as I’m unaware of their origins.  In any case, let’s get started.

Display a File Copy Dialog

The most common scripting method for copying files and folders in WSH is by means of the FileSystemObject (Scripting.FileSystemObject).  As you may have noticed, this is a silent process that does not display any form of progress dialog.  While there are workarounds in existence that can produce a functional command-line version, there is a way to produce the real thing.

A file copy progress dialog box is displayed any time that you copy files or folders using Windows Explorer.  This can be demonstrated by dragging and dropping files in My Computer.  It stands to reason that this is a feature of the Windows Explorer Shell.  In scripting, we do not have access to these specific Explorer APIs; however, we do have access to Explorer’s scriptable interface through the use of the Windows Shell object.  Since this object employs the native APIs, a progress dialog is displayed whenever the object is used to move or copy files and folders.

strSourceFolder = "C:Folder 1"

strDestFolder = "C:Folder 2"

 

Set objShell = CreateObject("Shell.Application")

 

Set objSourceFolder = objShell.NameSpace(strSourceFolder)

Set objDestFolder = objShell.NameSpace(strDestFolder)

 

result = objDestFolder.CopyHere(objSourceFolder.Items)

This simple example uses the Windows Shell object to perform a file copy procedure.  The Shell object’s NameSpace method is first used to create Folder objects for the source and destination folders.  (The Items property returns a collection of File and Folder objects contained in a Folder).  The CopyHere method is then used to initiate the copy process.  You may also use the MoveHere method instead if you wish to perform a Move or Rename operation.

Const sFOF_SILENT                = 4    ‘Do not display a progress dialog box.

Const sFOF_RENAMEONCOLLISION     = 8    ‘Rename if target file already exists.

Const sFOF_NOCONFIRMATION        = 16   ‘Respond with "Yes to All" for any dialog box that is displayed.

Const sFOF_ALLOWUNDO             = 64   ‘Preserve undo information, if possible.

Const sFOF_FILESONLY             = 128  ‘Perform the operation on files only (not on folders) if wildcard (*.*) is specified.

Const sFOF_SIMPLEPROGRESS        = 256  ‘Display a progress dialog box without showing file names.

Const sFOF_NOCONFIRMMKDIR        = 512  ‘Create destination directory if required.

Const sFOF_NOERRORUI             = 1024 ‘Do not display a user interface if an error occurs.

Const sFOF_NOCOPYSECURITYATTRIBS = 2048 ‘Do not copy the security attributes of the file.

Const sFOF_NORECURSION           = 4096 ‘Only operate in the local directory. Don’t operate recursively. (Default behavior)

Const sFOF_NO_CONNECTED_ELEMENTS = 9182 ‘Do not copy connected files as a group. Only copy the specified files.  (Win 98SE and higher)

The MoveHere and CopyHere methods also accept a second parameter that specifies shell settings to be used during the operation.  These constants must be added to your script if you do not wish to use the default settings.

{mospagebreak title=Implementing Password Masking}

Implementing Password Masking

Okay, so you’ve created a script that requires a user to enter a username and password.  Perhaps you’re mapping a network drive or accessing a database.  For whatever reason, it would be nice to mask the password input.  Unfortunately, VBScript’s InputBox method doesn’t provide a means of accomplishing this.

Thankfully, Microsoft’s developers thought of this.  There is a little-known COM component capable of masking passwords.  It does, however, have one small drawback.  It relies on the use of Standard Input and Output streams, so you can only use this method when running scripts under the Cscript engine.

If LCase(Right(Wscript.FullName, 11)) <> "cscript.exe" Then

    strPath = Wscript.ScriptFullName

    strCommand = "%comspec% /k cscript  " & Chr(34) & strPath & chr(34)

    CreateObject("WScript.Shell").Run(strCommand)

    Wscript.Quit

End If

We’ll begin our script with a snippet from volume one of this series.  This portion ensures that our script always runs under Cscript.

WScript.StdOut.Write "Enter Username: "

strUser = WScript.StdIn.ReadLine

The next section uses some basic techniques for accessing the standard streams.  It first writes a prompt for a username to the StdOut stream and then awaits the user response, which it reads from the StdIn stream.

Set ScriptPW = CreateObject("ScriptPW.Password")

WScript.StdOut.Write "Enter password: "

strPass = ScriptPW.GetPassword()

WScript.StdOut.WriteLine ""

Next, we turn again to the standard streams for the password prompt and response, but this time we do things a little bit differently. Instead of accessing the StdIn stream directly, we’re going to access it through the ScriptPW object.  This object works with the CMD environment and masks the StdOut stream while it is in use.  The ScriptPW’s GetPassword method does the magic.  It masks the real time output of the StdOut stream and returns the value of the StdIn stream.  Thus, it returns a text string containing the characters that were masked on screen.

WScript.Echo ""

WScript.Echo "You entered the password: " & strPass

This simple test demonstrates the validity of the code.

The ScriptPW object is available on Windows XP and Windows Server 2003. You can add the functionality to Windows Vista or older operating systems by copying the scriptpw.dll file from an XP or 2003 machine.  You’ll need to register the new COM object before use.

{mospagebreak title=Masking Passwords without ScriptPW}

Masking Passwords without ScriptPW

Okay, so using ScriptPW isn’t technically a workaround, although it is a little-known scripting secret.  But, what happens if you’re not on a machine running Windows XP or Server 2003 and don’t have access to the scriptpw.dll file?

I’m glad you asked.  That will allow me to introduce a workaround.

This workaround makes use of HTML’s form inputs.  As you may know, HTML has a form input element specifically for receiving passwords.  It’s a specialized input box that employs password masking.  The example in this script works with an HTML page and reads the values from the HTML form.

The code in this workaround is slightly complex.  I want you to see the code in its entirety first, then I’ll explain the key parts.  To begin, let’s look at the HTML page required.

<html>

<head>

<title>Please Enter Your Password</title>

<script language="VBScript"><!–

   Sub RunScript

       OKClicked.Value = "OK"

   End Sub

 

   Sub CancelScript

       OKClicked.Value = "Cancelled"

   End Sub

// –></script>

</head>

<body>

<font size="2" face="Arial">Password:&nbsp;&nbsp;&nbsp; </font>

<font face="Arial">

<input type="password" name="UserPassword" size="40"></font>

<p>

<input type="hidden" name="OKClicked" size = "20">

<input id="runbutton" class="button" type="button" value=" OK " name="ok_button"

   onClick="RunScript">&nbsp;&nbsp;&nbsp;

<input id="runbutton" class="button" type="button" value="Cancel" name="cancel_button"

   onClick="CancelScript">

</body>

</html>

This HTML page has two crucial parts:  the first is the HTML form and the second is a VBScript in the HEAD section of the document.

This example does use VBScript, therefore it will need to be run in Internet Explorer.

The basics of this HTML form aren’t important.  What is important is the use of the password input box and the id that has been given to it.  Notice also that there are two buttons.  One is used to “submit” the form; the other is used to cancel submission.  You should also notice that both have the same id.  While having two elements with the same id is a violation of coding standards, it does provide us with a quick and dirty method of passing two possible values to our script without needing to check two different elements.

{mospagebreak title=More on Password Masking without ScriptPW}

Next, we’ll take a look at the VBS code that uses this HTML page.  It’s a simple login script that requires the user to enter a password using the HTML page you’ve just created.

strPath = Left(WScript.ScriptFullName, Len(WScript.ScriptFullName) – Len(WScript.ScriptName))

To begin, we’re going to need to know the path to the HTML page.  Assuming it’s in the same directory as the current script, this line is a very efficient way of finding that path.

On Error Resume Next

 

Set objIE = WScript.CreateObject("InternetExplorer.Application", "IE_")

objIE.Navigate "file:///" & strPath & "Password.htm"

objIE.ToolBar = 0

objIE.StatusBar = 0

objIE.Width = 400

objIE.Height = 350

objIE.Left = 300

objIE.Top = 200

objIE.Visible = 1

Next, we’re going to create an instance of Internet Explorer and load the HTML page.  I’ve added the On Error Resume Next statement to prevent any problems if outside errors occur.  Now we need the script to wait for the user to enter information in the form.

Do While (objIE.Document.Body.All.OKClicked.Value = "")

   WScript.Sleep 250

Loop

This Do loop does that quite nicely.  It checks the value of the OKClicked element and loops around a Sleep statement until that value is not empty.  (If you look back at the HTML, we’re assigning a distinct value for both button responses.  If OKClicked is empty, it’s because neither button has been clicked yet.)

strPassword = objIE.Document.Body.All.UserPassword.Value

strButton = objIE.Document.Body.All.OKClicked.Value

objIE.Quit

WScript.Sleep 250

With the form submitted, it’s time to retrieve the contents of the password field.  Notice that I’m also retrieving the OKClicked value.  This will allow me to determine if the user clicked the Cancel button.

If strButton = "Cancelled" Then

   WScript.Quit

Else

   WScript.Echo strPassword

End If

Finally, a simple check against OKClicked determines whether the user canceled or entered a password.  Of course, in a production environment, you wouldn’t stop here.  You would want to verify that the password field isn’t empty and validate it.

But that’s enough for today, and that also wraps up the second volume of Nilpo’s Scripting Secrets.  Stick around for even more great scripting tips.  Until next time, keep coding!

[gp-comments width="770" linklove="off" ]