How can I use the common Save As dialog from VBScript?

Question

I'd like to have my VBScript display the Windows Save As dialog box, but I could not find out how to do it.

Using this code:

Dim sfd
Set sfd = CreateObject("UserAccounts.CommonDialog")
sfd.ShowOpen

I can get an Open dialog, but there is no ShowSave method for this object (as there seems to be for a similar object in Visual Basic non-script).

I searched StackOverflow and googled for "[vbscript] save dialog" (and with "Windows Script Host"), but I only found threads about accessing common dialogs from web pages and a solution for the BrowseForFolder dialog and nothing really about calling the Save dialog.

Actually, I can use the Open dialog for my purpose, because all I need is a file name... but as I'd like to save something to the selected path, a "Save As" in the title bar of the dialog would be more appropriate.

Enlargement

"UserAccounts.CommonDialog" only works on Windows XP. It won't work under Windows Vista or later. Is that relevant for you? – Selfmade

Well... at the moment, no, but a future-proof solution would probably be better. Thank you for this hint. – Enlargement

+1 for an excellent question. The more I Google this, the more it looks like there really isn't a universal solution. The stuff there is will only work on Windows XP (not earlier or later versions) and/or has external dependencies. Some examples even open Internet Explorer and use its dialog box while hidden, which seems like a really bad idea to me. There's also no way to call native Win32 APIs from VBScript, so I'm almost ready to conclude there's no solution. Is an external dependency (like a DLL file you have to include with the script), or using a compiled language like VB 6, an option? – Selfmade

In the end, language and form of the executable are not important, so I could certainly rewrite the script. Everything that does not require additional software to be installed on the target machine except standard Windows components is possible in theory but as the script fulfills only a simple task it would be nice to avoid special dependencies and satellite files. – Enlargement

On > social.technet.microsoft.com/Forums/en-US/ITCG/thread/… there is a way described how to get UserAccounts.CommonDialog to run under Windows Vista and 7. Did not test it, though. – Thaxton

@Nubok: The solution that's provided doesn't actually use UserAccounts.CommonDialog. Instead, it uses MSComDlg.CommonDialog found in comdlg32.dll which you'll have to download and register yourself, if you don't have Visual Studio installed on the machine (not a likely scenario for clients). The last answer also indicates that there may still be problems with the approach using VBScript. – Selfmade

Answer 1

I can definitively say that there is no solution to show a Save As dialog box from VBScript under versions of Windows other than XP without relying on some external dependencies that you must install and register yourself. Aside from the obvious interference this causes with regards to an easy, drag-and-drop deployment of your script, it also brings up a whole host of other issues related to security and permissions, particularly by-passing UAC on the client's machine to install and register a dependency DLL.

The solutions that have been proposed so far rely either on a DLL file that just so happens to be included with Windows XP, invoking the Save As dialog box from Windows XP's User Accounts control panel, and/or installing a piece of software only for it to leave behind the MSComDlg DLL after it is uninstalled that you can then use from a VBScript. None of these solutions truly satisfy the above requirements, and none of the provided answers has even considered the possible security roadblocks that would arise with their proposed solutions, as I alluded to above.

And since you can't make calls directly to the Windows API (which ever-so-conveniently includes just such a Save As dialog) from VBScript (not only because it would pose a security risk, but also because of VBScript's loose [lack of?] typing), that pretty much leaves anyone wanting to do this out in the cold. As well, the inability to make API calls also precludes the use of any hacks like calling SetWindowText to change the caption of the Open dialog, as suggested in the question.

I realize that this is not the answer everyone was wanting. It's not even the answer I was wanting. But alas, it's the correct answer.

That being said, here are a couple of possible workarounds:

1. If you're leaning towards accepting any of the already-suggested answers, you've already decided to introduce an external dependency on a DLL file to your VBScript deployment. Once you've made that leap, why bother with "borrowing" or otherwise hijacking a DLL from some other source? Just make once yourself. It's trivial to wrap the native common dialog functions provided by the Windows API into an ActiveX DLL using Visual Basic 6, which can then be called by your VBScript. The risks are minimal, since almost any modern version of Windows can be expected to already have the Visual Basic run-time installed, and since you presumably already know VBScript, banging out some code in VB 6 shouldn't be a very difficult undertaking. You can include whatever custom functionality that you want, and most importantly, you'll be in complete control. You won't have to worry about other application's uninstallers removing the DLL that your script requires, you won't have to futz with installing and uninstalling some random, deprecated application, and you won't have to just cross your fingers and hope. We know, as programmers, that's never a good option.

   And yes, I recommend actually wrapping the common dialog functions exposed by the Windows API, rather than relying on the common dialog OCX (comdlg32.ocx) provided by Visual Basic. It has its share of problems in Windows 7, and it's not going to get you the gorgeous new dialogs that the later versions of Windows now provide. An excellent article explaining everything you need to know about the Open and Save Common Dialog APIs and how to use them in VB 6 is available here on VBnet. Of course, if you really want to go all out, there's loads of interesting stuff you can do with common dialogs, all documented (with code!) here on VB Accelerator.

2. But now that I have you all convinced to write an ActiveX DLL in VB 6 that wraps the common dialog functionality to use in your VBScript, I have to ask the question: Why stop there? Once you've made the leap to writing some code in VB 6, why not move all of your code into VB 6? Sure, it's a "dead" language and all, but it's not like VBScript is terribly active either. As I mentioned before, the difference in syntax is virtually nil, and the learning curve for a VBScript developer is about as shallow as one could expect. Plus, you get all of the benefits of a full IDE, static typing, (slightly) better error handling, blah blah blah. Oh yeah, and being able to make direct calls to the Windows API functions. The only real benefit to VBScript is its ubiquity, but it's been years since you could find a computer without the VB runtime installed. Not to mention, if you're writing an application that requires common dialog boxes, you're probably engaging in a dialog with your users: The forms capability of full VB might begin to come in handy at that point. But perhaps the biggest and most important advantage of choosing to go this route is that you eliminate any need to register (or include) an external "satellite" DLL—a simple VB 6 application will run with only the EXE on any computer that has the VB run-time installed, which is included at least up through Windows 7.

3. And finally, in case you're all sorts of excited about moving up from the lowly VBScript to the full-featured VB 6, I feel compelled to throw another wrench into the equation: Why not move all the way up to a language like VB.NET? Again, there are all sorts of new features offered in VB.NET thanks to the .NET Framework, but it shouldn't take more than a few weeks for a decent VB/VBScript developer to begin to feel comfortable writing apps in VB.NET. They probably won't have a full understanding of the .NET Framework, and they certainly won't have developed good object-oriented design practices, but at least they will be moving in the right direction. Almost anything that you can do in VBScript (or even VB 6), you can do in VB.NET. And generally, it requires even less fuss than before, thanks to the immense functionality exposed by the .NET Framework. The drawback, of course, is that your app now requires the .NET Framework be installed on the user's computer, which isn't quite as ubiquitous as the VB 6 run-time (although it's much more common now than even just a few years ago).

So I hear you saying those weren't the workarounds you were hoping to hear? Yeah, me neither. I'm not that guy who tells people to drop everything and learn a new language. If VBScript continues to work for you, go for it. But if you're at that point where you start to strain at its limitations, it's probably time to make the leap.

Selfmade

I personally don't think that it is a good idea to recommend VB 6 since it it has been retired and deprecated (i. e. no security fixes anymore). – Thaxton

@Nubok: Yeah, I agree. I sort of addressed that, particularly in the third suggestion. But then again, consider the person to whom this advice is targeted. They're already using VBScript, so the advantage of moving to VB 6 isn't to upgrade their code, but just as a simple lateral move that gains them some extra technology with almost zero expense. Besides, Microsoft has been strongly positioning the .NET platform (and even more so now with PowerShell) to obsolete VBScript—if you don't consider it "deprecated" now, you won't consider VB 6 such either. – Selfmade

@Code Gray I don't entirely agree. While - as I already remarked - there won't be any security updates for VB 6, according to en.wikipedia.org/wiki/Active_Scripting#Deprecation Active Scripting is still supported by Microsoft's Sustaining Engineering Team. – Thaxton

I usually am more into C# anyway... When I do VBScript I just want to avoid the overhead of creating projects etc. I hoped there was a quick way to add this dialog for a script as it is a standard (Windows API) feature. But as there seems to be no general solution, as you explained, I'm going live without it. Thank you. – Enlargement

Answer 2

The secret to using the common dialog from VBScript (or VBA or JScript, for that matter) is that you have to have its license installed on your machine. Certain development tools, such as Visual Basic 6, will install the license, but it's also installed by the free Microsoft HTML Help Editor (this is a pretty old app). The interesting thing is that if you install and then uninstall the HTML Help Editor, it leaves the Common Dialog License in place. For this reason I would consider the license to be freely available and so will include the registry entry it creates here in my answer:

In HKLM\Software\CLASSES\Licenses\4D553650-6ABE-11cf-8ADB-00AA00C00905, set the (Default) entry to gfjmrfkfifkmkfffrlmmgmhmnlulkmfmqkqj.

Once that's in place, you can create these dialogs from within a VBScript using code like this:

Set objDialog = CreateObject("MSComDlg.CommonDialog")

To launch a file save dialog, use the ShowSave method as in this code:

objDialog.ShowSave

Of course this object has a bunch of other methods and properties, and you'll probably want to configure the appropriate properties before launching the dialog. For example, you can set the file filter so only certain file extensions are shown in the dialog. There's a nice reference to the control on the MSDN site here: http://msdn.microsoft.com/en-us/library/aa259661%28v=vs.60%29.aspx.

Hope this helps. Let me know if you have any questions.

Corrosive

Sadly, it didn't work on my machine. I could not create an MSComDlg.CommonDialog object after setting this Registry key. I suppose the prerequisites to use this are to be found in the other comments on this page (maybe you or sbd. else could add them to this answer?). But even if it did, generally one would have to assert or check this Registry key to be set before creating the dialog. Correct me if I should be wrong, please. Nevertheless, thank you for your investigation! – Enlargement

I have the same problem although I did what you suggested in the registry. It shows me an error message that says "An ActiveX composant can not create an object: MSComDlg.CommonDialog". My computer is Windows 7 in case that can have something to do with it (even if I doubt it). – Vadose

@DonaldDuck: maybe run tested it on 64-bit OS? I had to run the 32-bit version of WSH interpreter on my 64-bit w10 for the script to show the File dialog: %WINDIR%\SysWOW64\cscript <...>\demo.vbs. This means just prepending %WINDIR%\SysWOW64` as the path to the cscript` or wscript names that you invoke. Not sure how to do this using GUI only. – Plumley

Also I am not sure if the license key is needed on w10 [Version 10.0.19044.2965]. I added the key when I started my debugging experiments, now I removed it, and the script still works. – Plumley

Answer 3

If you have some degree of control over the systems on which you'll be deploying this, and can be reasonably certain that they have either Visual Studio or Microsoft HTML Help installed, you can use code like the following:

function filedialog(filt, def, title, save)
    set dialog = CreateObject("MSComDlg.CommonDialog")
    dialog.MaxFileSize = 256
    if filt = "" then
        dialog.Filter = "All Files (*.*)|*.*"
    else
        dialog.Filter = filt
    end if
    dialog.FilterIndex = 1
    dialog.DialogTitle = title
    dialog.InitDir = CreateObject("WScript.Shell").SpecialFolders("MyDocuments")
    dialog.FileName = ""
    if save = true then
        dialog.DefaultExt = def
        dialog.Flags = &H800 + &H4
        discard = dialog.ShowSave()
    else
        dialog.Flags = &H1000 + &H4 + &H800
        discard = dialog.ShowOpen()
    end if
    filedialog = dialog.FileName
end function

Also, adapting one of the other answers to this question into VBScript code (thanks @oddacorn!), you should add this function if you aren't reasonably certain that your users will have VS or HTML Help. Call this function on program startup. Don't worry if you already have the key; in that case, this has no effect. This should work on a standard user account without admin rights.

'Make the MSComDlg.CommonDialog class available for use. Required for filedialog function.
function registerComDlg
    Set objRegistry = GetObject("winmgmts:\\.\root\default:StdRegProv")
    objRegistry.CreateKey &H80000001, "Software\CLASSES\Licenses\4D553650-6ABE-11cf-8ADB-00AA00C00905"
    objRegistry.SetStringValue &H80000001, "Software\CLASSES\Licenses\4D553650-6ABE-11cf-8ADB-00AA00C00905", "", "gfjmrfkfifkmkfffrlmmgmhmnlulkmfmqkqj"
end function

Note that I adapted the filedialog function from the "View Source" of the VBScript code in the HTML here; on modern web browsers, it appears that the HTML they use to render the code samples doesn't display correctly (tested on IE 8 and Chrome). But fortunately the code is still there in the View Source.

I found one thing that was critical to making this work on Windows 7 (SP1, fully patched); you must set dialog.MaxFileSize = 256 or you will get a run-time error.

That is, the following code fails on Windows 7 SP1, but probably works on older versions of Windows:

Set x = CreateObject("MSComDlg.CommonDialog")
x.ShowSave

Dobson

do you remember whether was this 32- or 64-bit OS installation? I needed to apply some other measure for it to run to run on my w10 [Version 10.0.19044.2965]. – Plumley

Answer 4

After looking for ages, I've found jsShell - Shell Component at jsware.net. The zip file contains jsShell.dll ^{176 kB}, a vbscript to register the dll ^{basically regsvr32.exe jsShell.dll}, demo scripts and clear documentation.

The DLL works well in Windows 7 and provides several useful methods, including the Open/Save dialog:

Dim jsS, sFileName
jsS = CreateObject("jsShell.Ops")
' Save as dialog
sFileName = jsS.SaveDlg("<title>", "exe") ' Example: Filter by exe files
sFileName = jsS.SaveDlg("<title>", "")    ' Example: No extension filter
' Open dialog
' Example: Filter by exe, initial dir at C:\
sFileName = jsS.OpenDlg("<title>", "exe", "C:\")

When no file is selected, sFileName is an empty string.

Orndorff

Answer 5

On http://blogs.msdn.com/b/gstemp/archive/2004/02/18/75600.aspx there is a way descibed how to show an Save As dialog from VBScript.

Note that according to http://www.eggheadcafe.com/software/aspnet/29155097/safrcfiledlg-has-been-deprecated-by-microsoft.aspx SAFRCFileDlg has been deprecated by Microsoft.

Thaxton

Yeah, but a little more than deprecated. The DLL file is not included with any version of Windows other than XP, so this is hardly an out-of-the-box solution. You could just write a simple wrapper around the standard Win32 dialog in C++, or even C#/VB.NET and include that with your script, if you're going to have external dependencies like DLLs. – Selfmade

Answer 6

I just made a shell, linked it to a asp website, made the website read a directional tag - which i loaded the file location into, and the asp page opens up the file dialog immediate within that file location, with the filename also specificed through directional tags. Once saved, the shell disappears.

If it's a limitation of the website direcitonal tags ie (blah.com/temp.aspx?x=0&y=2&z=3)

store the information in a SQL db, or flat files, there are a ton of workarounds, but what above is said is true. VBS won't cut it internally.

Circularize

Answer 7

Private Sub cmdB1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles cmdB1.Click
    Dim objExec, strMSHTA, wshShell, SelectFile

    SelectFile = ""

    ' For use in HTAs as well as "plain" VBScript:
    strMSHTA = "mshta.exe ""about:" & "<" & "input type=file id=FILE>" _
             & "<" & "script>FILE.click();new ActiveXObject('Scripting.FileSystemObject')" _
             & ".GetStandardStream(1).WriteLine(FILE.value);close();resizeTo(0,0);" & "<" & "/script>"""

    wshShell = CreateObject("WScript.Shell")
    objExec = wshShell.Exec(strMSHTA)

    SelectFile = objExec.StdOut.ReadLine()
    Me.txtT0.Text = SelectFile
    objExec = Nothing
    wshShell = Nothing
    strMSHTA = Nothing
End Sub

Loveless

Answer 8

I just found a solution in this site It is fully commented and works well in Windows 10

Here is the code that returns the folder as a string (I tried in three different start folders):

Option Explicit

WScript.Echo BrowseFolder( "C:\Program Files", True )
WScript.Echo BrowseFolder( "My Computer", False )
WScript.Echo BrowseFolder( "", False )


Function BrowseFolder( myStartLocation, blnSimpleDialog )
' This function generates a Browse Folder dialog
' and returns the selected folder as a string.
'
' Arguments:
' myStartLocation   [string]  start folder for dialog, or "My Computer", or
'                             empty string to open in "Desktop\My Documents"
' blnSimpleDialog   [boolean] if False, an additional text field will be
'                             displayed where the folder can be selected
'                             by typing the fully qualified path
'
' Returns:          [string]  the fully qualified path to the selected folder
'
' Based on the Hey Scripting Guys article
' "How Can I Show Users a Dialog Box That Only Lets Them Select Folders?"
' http://www.microsoft.com/technet/scriptcenter/resources/qanda/jun05/hey0617.mspx
'
' Function written by Rob van der Woude
' http://www.robvanderwoude.com
    Const MY_COMPUTER   = &H11&
    Const WINDOW_HANDLE = 0 ' Must ALWAYS be 0

    Dim numOptions, objFolder, objFolderItem
    Dim objPath, objShell, strPath, strPrompt

    ' Set the options for the dialog window
    strPrompt = "Select a folder:"
    If blnSimpleDialog = True Then
        numOptions = 0      ' Simple dialog
    Else
        numOptions = &H10&  ' Additional text field to type folder path
    End If

    ' Create a Windows Shell object
    Set objShell = CreateObject( "Shell.Application" )

    ' If specified, convert "My Computer" to a valid
    ' path for the Windows Shell's BrowseFolder method
    If UCase( myStartLocation ) = "MY COMPUTER" Then
        Set objFolder = objShell.Namespace( MY_COMPUTER )
        Set objFolderItem = objFolder.Self
        strPath = objFolderItem.Path
    Else
        strPath = myStartLocation
    End If

    Set objFolder = objShell.BrowseForFolder( WINDOW_HANDLE, strPrompt, _
                                              numOptions, strPath )

    ' Quit if no folder was selected
    If objFolder Is Nothing Then
        BrowseFolder = ""
        Exit Function
    End If

    ' Retrieve the path of the selected folder
    Set objFolderItem = objFolder.Self
    objPath = objFolderItem.Path

    ' Return the path of the selected folder
    BrowseFolder = objPath
End Function

Ryurik

Welcome to Stack Overflow Alex Casal. While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Answers that are little more than a link may be deleted. – Mainstream

This does not answer the question as it offers a Browse Folder dialog, not a Save As dialog. The latter allows you to choose a file name. The dialog in the answer does not. – Enlargement

Answer 9

Set objDialog = CreateObject( "SAFRCFileDlg.FileSave" )

' Note: If no path is specified, the "current" directory will
'       be the one remembered from the last "SAFRCFileDlg.FileOpen"
'       or "SAFRCFileDlg.FileSave" dialog!
objDialog.FileName = "test_save.vbs"
' Note: The FileType property is cosmetic only, it doesn't
'       automatically append the right file extension!
'       So make sure you type the extension yourself!
objDialog.FileType = "VBScript Script"
If objDialog.OpenFileSaveDlg Then
    WScript.Echo "objDialog.FileName = " & objDialog.FileName
End If

Engelhart

Of course, if you'd actually read the other answers to the question, you'd know that this is not a solution. It's limited only to Windows XP, a 10 year old operating system that most people are no longer using. It's neither backward nor forward compatible, a pretty useless approach that explicitly fails to satisfy the requirements of the asker. Next time, try reading the question more carefully and considering the other answers before copying and pasting code you find elsewhere on the web. – Selfmade