Auto-confirm with PopUp
Used appropriately, PopUp is a powerful addition to any scripter's toolbox.
- By Chris Brooke
Scripting is all about automating repetitive tasks that would otherwise take hours or even days. By its very nature, an automated task should be one that requires no intervention. In the real world, however, this is rarely the case. Some automated tasks require lots of intervention
while others require at least occasional verification, along the lines of "Hit to proceed" or "Do you want to overwrite this file?"
Whenever I need this type of occasional confirmation in a script, I tend to use the "messagebox" (MsgBox) function. It stops script execution and waits for a response, such as clicking . The problem is that it will wait forever for a response that 99 times out of 100 is going to be simply clicking . Meanwhile, your script just sits there.
Other times a script may not require interaction, but you do want to display status information. For this, I tend to use WScript.Echo. This works fine as long as you know your scripts are going to be run using CScript.exe. All "echoed" data is displayed in the command window and script execution proceeds. However, if WScript.exe is used to run the script, or someone runs it by double-clicking on it in Explorer, all those "echoed" messages will be displayed in a messagebox
window—each time forcing a mouse-click before the script will continue. Now, if you're the only person who ever runs your scripts, it's easy to remember to always use CScript. However, if you ever send out scripts for other admins or even users to run, you can never be certain they'll run the script as expected.
Thankfully, there's an alternative for either of these cases: the PopUp function of the WScript.Shell object. This little gem works almost exactly like a messagebox, except that it allows you to enter a timeout value in seconds. If the user doesn't respond to the PopUp, the script will continue after the timeout expires. You can then code the script to respond appropriately. Here we instruct the script to take different actions on its own, rather than relying on the user to click or .
Display notifications with default
timeout so that script continues
This script demonstrates the PopUp function
C:\cscript PopUpTimeout.wsf /File:c:\logfile.txt
helpstring="The name of the file to save data"
If objFSO.FileExists(strFilename) Then
("Adding Entry to File." & vbCrLf & "Click Cancel to abort",_
10, "Creating Entry",vbInformation+vbOKCancel)
If iReturn=vbCancel Then
"The Entry was not added!", 5, _
'Open the file for appending
Set objFile=objFSO.OpenTextFile(strFilename, 8)
objFile.WriteLine "File updated: " & Now
'Create the file
("Do you want to create the file: " & strFilename, _
10, "Create File?",vbQuestion+vbYesNo)
If iReturn<>vbYes Then
"The File was NOT Created!", 5, _
"File Creation Failed!",vbExclamation+vbOKOnly
Set objFile=objFSO.CreateTextFile(strFilename, 1)
objFile.WriteLine "Log file:"
objFile.WriteLine "File updated: " & Now
Just a Mouse Click Away
This script starts by taking a file name as a command-line argument. The script then checks to see if the file exists. If it does, it will add the data—in this case, simply a date/time stamp—to the file. If the file doesn't exist, the user is asked if the file should be created.
Creating the File
We use a simple If/Then statement to
verify the user selected to create the file. Any other input (including
waiting until the PopUp times out)
causes the script to exit without the file being created. If you wanted to, you could check for each possible entry and process accordingly. For the record, allowing the PopUp to timeout returns a value of -1, which means the script will time out.
Adding the Entries
The logic for this section is very
similar to creating the file, except that doing nothing results in the script
proceeding, rather than stopping. The only action that will cause the script to stop is clicking .
Not Waiting for an Answer
We used PopUps for the "failure" messages in each section, as well. The difference here is that we didn't wait for a result. Indeed, we aren't even checking for a returned value. That's why the only button in these Windows was , because at this point it doesn't matter what you do; the script is going to quit.
Each of these methods has its place. The first method is useful when you need to verify entry before proceeding. If no one is sitting at the computer to provide that verification, you would prefer the script exit gracefully, rather than wait for an answer in perpetuity. On the other hand, sometimes you just want to provide the opportunity to change a setting or file location from the default. If no answer is given in the required time, the default values are used and execution continues. Finally, there are times when you simply want to provide a notification to the user, but not risk inadvertently halting the script with a messagebox.
PopUp isn't a perfect replacement
for WScript.Echo and won't substitute for every MsgBox. Used appropriately,
however, it's a powerful addition to your scripting toolbox.
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to firstname.lastname@example.org.