As you progress into more detailed and more powerful code, you will find yourself focusing more and more on how your scripts appear to your users. Using common Windows dialog boxes will give your script a familiar, comfortable feel while appearing more like a fully functional application.
You've all seen the classic File Open and File Save dialog boxes in Windows. These standard dialogs are provided by the Common Dialogs Control that ships with Windows. Updates are made available via subsequent releases of the Visual Basic runtime environment and some Microsoft applications.
The Common Dialogs control is housed in the comctl32.dll library in your System32 directory. It is a registered component and is therefore made available to any application in the Windows environment.
As with any object, you can connect to the Common Dialogs control and use any of its available methods. In a standard programming language, such as Visual Basic or C++, this is a fairly simple task. However, it's not quite so simple in WSH.
Take the time to read this article slowly and thoroughly. WSH does not have native support for Common Dialogs. Whether the lack of support was intentional or a mere oversight is mostly irrelevant. The fact remains that the normal conditions that scripting was designed for have no real need for Common Dialogs.
But as is generally the case with programming technologies, the uses for scripting have evolved far beyond their intended purpose and, thus, the interest in Common Dialogs implementation has been born.
Please keep in mind that due to the nature of the examples that follow, they may not work in all situations or under every condition. These are all workarounds! While I will be making the attempt to provide code that should work, it's not possible for me to accurately forecast every scenario that may arise.
One final suggestion before we dive into things: if you are interested in applying a GUI to your scripts in an effort to make them look like real applications, you may want to consider the use of HTML applications.
HTAs are a scripting technology that allows you to house code in standalone web pages. This allows you to design a sort of UI with the use of forms and other web elements in full HTML and CSS. You may find this a more suitable solution.
Using the Microsoft Common Dialogs control is fairly straightforward. You initialize the object by connecting to its namespace, assign the dialog's attributes, and then call its display method. Here's a quick example that opens the familiar Open File dialog.
Set objDlgs = CreateObject("MSComDlg.CommonDialog")
objDlgs.Filter = "All Files(*.*)|*.*|VBScript Files(*.vbs)|*.vbs"
objDlgs.FilterIndex = 2
objDlgs.MaxFileSize = 128
objDlgs.ShowOpen()
WScript.Echo objDlgs.FileName
The Filter property tells the dialog box what to offer in the file types drop-down box. The FilterIndex property sets the default.
You must use the MaxFileSize to set the maximum name length or the control will generate an error.
Finally, a call to the ShowOpen method returns a string containing the file name and path. And empty string is returned if the user presses the Cancel button.
Set objDlgs = CreateObject("MSComDlg.CommonDialog")
objDlgs.Filter = "Text Files(*.txt)|*.txt"
objDlgs.FilterIndex = 1
objDlgs.MaxFileSize = 128
objDlgs.ShowSave()
WScript.Echo objDlgs.FileName
The Save dialog works in the exact same way. The code above opens a Save dialog with the default file type set to Text Files.
The Common Dialogs control offers many more familiar dialogs that you can implement in your scripts. Among these are Choose a Color, Choose a Font, and the Print dialog.
So why am I touching on these so briefly? Well, because this probably will not work for most of you. While the Common Dialogs control is installed on every Windows system by default, it is a licensed control. That means that its functionality is based upon which license is installed on the machine.
There are two types of licenses: runtime and development. A runtime license (the default) only allows the common dialogs to be called from software that was written with a development license. As you can probably guess, to use this control in WSH you would need to have a development license installed on your machine.
A development license is installed by Visual Basic 6.0, Visual Studio, or Microsoft Office Developer Edition. So you can only use this control on any machine that has one of those titles installed. Since this rules out most scenarios, I didn't feel there was much point in spending a lot of time on this.
Let's take a look at some of the workarounds available that can be used as alternatives to the Common Dialog control.
If you can't call the Common Dialog control directly, it makes sense to try and call it from an application that can. However, this seems like a bit of a stretch. The Common Dialog control would be called within the code of the application so we would need to find a way to trap the results it returns.
To do that, we'll look to Internet Explorer. If you create a web page with a Browse form button, clicking the button will launch the File Open dialog box. The results of that dialog are then returned to the button's accompanying text box.
Set objIE = CreateObject("InternetExplorer.Application")
This example goes a little further than the VBS scripting you're probably used to because we're also implementing some browser scripting as well.
Browser scripting relies on the Document Object Model (DOM) for controlling web page elements. In this case, we're using client-side scripting to control a web form. The web page itself was also created with the DOM.
We begin by loading a blank HTML page in Internet Explorer using the IE object's Navigate method. Then we write an HTML string to the page using the Write method of DOM's Document object.
We make sure that the form field is in focus and then simulate a mouse click on the Browse button. This brings up the Open file dialog box. Once the user makes a selection, the value is returned to the form field.
We finish up by reading the field's contents with the Value property. Make sure to use IE's Quit method to close the application when you're finished. Otherwise, the process will remain running in the background.
So why don't I like this method? Well, first off it does not give you any control over the dialog box's appearance or functionality. It's very cut-and-dry. Second, I don't like the idea of having to launch another application if I can help it.
This does work as a viable alternative to the Common Dialogs control, however, because it's a pretty safe bet that IE will be installed on every machine.
The final reason I don't like this approach is because you only have access to a File Open dialog. What if I want to save a file? Technically, I could still use this since we're only returning a string but that could be confusing to our users.
Let's take a look at the IE object's File Open dialog in action. We'll use it to make a backup copy of a file. The file will be copied to the same directory with a BAK extension.
WScript.Echo "Please select the file you would like to copy."
Set objIE = CreateObject("InternetExplorer.Application")
Set objFso = CreateObject("Scripting.FileSystemObject")
Set objFile = objFso.GetFile(strFile)
objFile.Copy(objFile.Path & ".bak")
WScript.Echo "Backup completed."
This is a pretty basic script. The IE Object's File Open dialog returns a file path. We use that file path along with the FileSystemObject's GetFile method to create a File object and make a copy of it.
I also decided to show a different looping method for checking if Internet Explorer is busy. I've replaced the Do Until...Loop with its converse Do While...Loop.
Let's take a look at another example. In this example, we'll use the File Open Dialog to choose a file. Then we'll create a shortcut on the Desktop to that file.
WScript.Echo "Please select a file to make a shortcut to."
Set objIE = CreateObject("InternetExplorer.Application")
Now I've taken the result of the Open dialog box and used the file path to create a Desktop shortcut to the file. I've implemented the WshShell object coupled with its WshShortcut object to do the dirty work.
I've also changed up the looping scheme again replacing the Do While...Loop with a While...Wend loop. I've also used the With statement to shorten things up a bit and save myself some typing.
I've shown you how to implement Microsoft's Common Dialog control to present a more user-friendly script. As I've stated, these methods each have their own drawbacks. Be sure to stick around for part two of this series when I show you some more viable alternatives. Until next time, keep coding!
Windows Scripting 
Printing Documents in WSH
