Adobe Acrobat PDF Printer output filename on 64-bit OS…

Now that I’ve moved over to Windows 7 64-bit on my primary workstation, I’m in a new world of IT support that I didn’t expect from those extra 32 bits of OS horsepower. My MicroTek scanner is not supported, my HP 2800 Business Inkjet is not supported, and I recently discovered that a technique I use in my Visual FoxPro business application to pre-define the PDF output filename when using the Adobe Acrobat PDF printer driver mysteriously does not work on Windows 64-bit. So, I want to show the remedy in case others encounter this same problem. I’m explaining this from the perspective of a Visual FoxPro application, but the issue applies to all Windows applications, and the remedy can come from many programming languages.

Background… It’s well know that you can prevent the Adobe PDF printer driver from prompting the user to choose a path and filename for the output file by programmatically setting a certain registry key with a string value that contains the desired path and filename of PDF file you want to output. I use this technique to automatically set the path and filename for my users for the various PDF reports we generate to send out to our customers and vendors.

This magic registry key is located at: HKEY_CURRENT_USER\Software\Adobe\Adobe Distiller\PrinterJobControl.  So, you create a string value under that key with the path and name of the *application* that is printing the PDf, and then you set the value of that string value to the path and filename of the PDF you want to create.

Now, the path and filename of the application that is doing the printing is not always easy to figure out, so I can’t solve that mystery here for any given app that you may be using, but I do know (and I forget where I learned this) that for a Visual FoxPro application (.exe), the path and application name can be discovered from the VFP variable “_VFP.ServerName”. Of course, it’s up to you to decide the path and filename of the PDF output file you’re want to create.

So, to bring it all together, you add a string value named after the app that is doing the printing (for instance) “C:\Program Files\Microsoft Visual FoxPro 9\vfp9.exe” and you set the value of that string value to the filename you want the PDF to be called; i.e. “C:\TEMP\JMC_PO_MS2741C.pdf”

Well, that’s how it works on good ‘ole 32-bit OS.  Now, enter into the 64-bit world…

The issue is that the *application* name that the 64-bit OS sees as doing the printing is no longer the actual exe the user is running,  but rather some odd Windows exe named “splwow64.exe” (some spooler-like thingy that actually handles the printing which I learned about here ). So that’s the application name you have to use, and you do have to include the path. Since this spooler thingy exe runs from C:\Windows, the actual registry key that must therefore be created is “C:\Windows\splwow64.exe”.


So, with the PrinterJobControl registry key all programmatically setup as described above, when you actually fire off the Adobe PDF printer, the output name is already set and the user will not see the prompt dialog to choose the output path and filename.

Also, be aware that after *you* programmatically create and set the registry value, the Adobe PDF driver will actually delete that string value from the key right after the file is printed. Perhaps this is so the next app that prints won’t use the same name.

Finally, here’s the VFP code I use to set the values for both 32-bit and 64-bit OS’s. (This code uses an instance of the Registry class from the FoxPro FFC classes to work on the Windows registry). Again, this all works the same way whether you are using .Net, VFP, VB, or whatever. The main thing is to setup the registry value the right way.


        m.lcKeyPath = "Software\Adobe\Acrobat Distiller\PrinterJobControl"

       *– This RegKey setting works on 32-bit OS…
        oRegTools.OpenKey(@lcKeyPath, HKEY_CURRENT_USER , .T.)
        lcPrintingApplicationName = _VFP.ServerName
        oRegTools.SetKeyValue(lcPrintingApplicationName, “C:\TEMP\JMC_PO_MS2741C.pdf”)

        *– This is the "Application" name that the OS sees as doing the printing when running on a 64-bit OS…
        oRegTools.OpenKey(@lcKeyPath, HKEY_CURRENT_USER , .T.)
        lcSplWow64ProcessName = ‘C:\Windows\splwow64.exe’ && <— This is what the OS sees as what’s doing the printing…
        oRegTools.SetKeyValue(lcSplWow64ProcessName, “C:\TEMP\JMC_PO_MS2741C.pdf”)


Hopefully, this insight will save someone out there a little headache when working with the Adobe PDF printer driver on these super-duper 64-bit OS’es.

26 thoughts on “Adobe Acrobat PDF Printer output filename on 64-bit OS…”

  1. Hi Matt,
    I was googling for a problem about visual foxpro and I ran into your blog about the Adobe Acrobat PDF Printer output file name on 64-bit OS. I want to ask you can this work on a 32 bit Windows, or can you tell me a solution for the same problem in 32 bit Windows. I am a student and I don't work in Visual FoxPro, just helping my dad a little, who is a FoxPro programmer.
    Thanks in advance and cheers from Macedonia,
    Rankovski Gorgi

  2. Rankovski Gorgi – This article begins by explaining explain how this functions in 32-bit OS and shows the VFP code to do so (near the end), so if he uses Adobe PDF to create PDF files from within VFP, then he will be able to read this article an understand how to make it work.

  3. Ok, my appologies for disturbance, you can feel free to delete the comments, it was my fault that I didn't read the blog.
    Thanks a lot for the help 😉

  4. Thanks for the post! This just saved my butt!

    For those of running apps on 32 and 64-bit, here's some code which helps the same app work

    IF AT('(x86)', _vfp.ServerName) > 0
    lcProcessName = 'C:\Windows\splwow64.exe'
    lcProcessName = _vfp.ServerName

    oRegTools.SetKeyValue(lcProcessName, “C:\TEMP\JMC_PO_MS2741C.pdf”)


  5. For me on a Windows XP System, this does not work.
    It takes the path but still not the filename and continues to ask for the filename using a default filename from the VBA call "ActiveWindow.SelectedSheets.PrintOut"

  6. Wow dude, or should I say wow64 Dude! you nailed it! I’ve been trying to solve this for years. and only now did I dig deep enough to find you, which will allow us to get off Adobe 6 and use Adobe X with this solution. Thanks a bunch!

    1. I spoke too soon.
      the settings you mentioned did work for 64 bit, and we can generate PDF’s in MS Access without prompting the user for path and filename. That works great.

      However, Adobe keeps poping up and showing the PDF after it makes it.
      I am hoping to find a registry entry for disabling that.

      I found and cleared the checkboxes “View PDF Results” (for current user and all users), but it still shows the PDF. I suspect its because the Reg.entries override the checkboxes.

      I called Adobe and they said they dont support VB or any scripting language and say there is no way to do what I want.

      I am hoping to find a registry entry for disabling adobe from showing the pdf after it creates it. does anyone know how to do it?


      1. Have you tried this?:
        Right-click “Adobe PDF” and select Properties
        Click Printing preferences
        Click “Adobe PDF Settings” tab
        Ensure “View Adobe PDF results” is un-ticked

        On occasion this has been reset back to “ticked” – but then I was setting via Remote Desktop on the server.


        1. Great! It worked! I no longer get a view of the PDF after it is created!!!

          To clarify the steps (in WIndows 7):
          1. Open the Devices and Printers section from Control Panel
          2. Right-click “Adobe PDF” and select “Printing preferences”
          3. Click “Adobe PDF Settings” tab
          4. Ensure “View Adobe PDF results” is un-ticked

  7. So what am I doing wrong? Running Windows 7 64 and VFP 7 or VFP 9
    Stepping thru with debug, the OpenKey and SetKeyValue functions are failing (badkey). The key never gets created. Why would this be? Need some help, here’s what I have…

    SET CLASSLIB TO registry additive
    m.lcKeyPath = “Software\Adobe\Acrobat Distiller\PrinterJobControl”
    *– This is the “Application” name that the OS sees as doing the printing when running on a 64-bit OS…
    oRegTools.OpenKey(@lcKeyPath, ‘HKEY_CURRENT_USER’, .T.) && Note added quotes around HKEY_CURRENT_USER otherwise variable error, your example shows no quotes

    lcSplWow64ProcessName = ‘C:\Windows\splwow64.exe’ && <— This is what the OS sees as what’s doing the printing…
    oRegTools.SetKeyValue(lcSplWow64ProcessName, pdfFileName ) && pdfFileName set earlier dynamically with path and filename ie: s:\pdffiles\me1001-0001.pdf



    1. You cannot add quotes around HKEY_CURRENT_USER…. That’s the problem.

      That is a CONTSTANT, and, I failed to point out that you must reference an include file named “registry.h” which exists in the FoxPro install folder, and that’s where the string value for that constant will come from.

      That’s why the OpenKey() is failing.

      On my machine, that file lives in the C:\Program Files (x86)\Microsoft Visual FoxPro 9\ffc folder.

      I assume you know how to use reference an Include file. It varies depending on if you are working in a Form, Class, or Prg.

      For PRG, you do this

      #INCLUDE C:\Program Files (x86)\Microsoft Visual FoxPro 9\Ffc\registry.h

      1. Thanks so much and for the extremely quick reply! That was the problem, I didn’t have the include file registry.h
        It’s been along time since I’ve done anything in Foxpro, I am doing a data conversion of this old app and also exporting reports to pdf. This is the cats meow, thanks so much for posting this info!


  8. Anyway to prevent the pdf from being displayed. Seems like after it generates the 2nd one with no problem, it starts displaying the pdfs. So if I generate 10, I have 8 displayed. Seems to be resetting the View Adobe pdf results setting.


    1. To turn off the displaying of the PDF after it is created, Right-click on the PDF Printer icon in Printers, then click on “Printing Preferences”

      Then click on the “Adobe PDF Settings” tab, and un-check the “View Adobve PDF results” option

      1. To update this post, I probably posted my issue to quick. I had performed the previously mentioned steps, but whatever caused it is no longer happening. Works as stated, again, thanks for the help on this.

  9. Hi All,
    I have done all this i.e i set the registry entry for splwow64.exe and it set properly but when i execute report from command

    REPORT FORM (lc_temfrm + ‘.frx’) ;
    &lc_scope. ;
    &lc_forwhile. ;
    TO PRINT ;

    whete lc_temfrm is temporory report file name canbe like ‘0432649’ that is generated runtime the pdf file got created with report file name i.e. 0432649.pdf and not with the name i specified in regisru variables. also after the report form command get executed 2 more registry entry got created with new pdf file name.

    Please help

  10. Matt,

    Thanks for taking the time to make this post. I just now upgraded my Windows XP computer and my custom-built Access 2003 application to Windows 7 (64) and Access 2013. Testing my app, I found my use of PrinterJobControl didn’t work any more. Changed the one line of code from:

    AccessProgramPath = SysCmd(acSysCmdAccessDir) & “msaccess.exe”


    AccessProgramPath = “C:\Windows\splwow64.exe”

    and that fixed it!

    I did several searches until I came across your page as the 16th link for “acrobat xi disable prompt for filename distiller” in Bing (I know, I haven’t changed the default for IE on my new computer yet). Yours is the only page with this information on the entire Internet, apparently, including all of Adobe’s web pages.

    Best wishes to you.


  11. Required note:
    In the Printing Preferences option Adobe PDF Output Folder must be “Prompt for Adobe PDF filename”.
    Otherwise register tweaking is not taken into account, file name is generated by application and placed in folder specified by selected option.

  12. hi Matt Slay,

    What a great article. I tried the solution that you’ve shared the prompted save dialog box got suppressed but another issue came. The issue is the Adobe Printer got stuck while creating the pdf file. I posted the issue on StackOverflow, and still, no one has shared a better solution. I hope with your experience in the subject, this issue gets resolved. Please take a look :


Leave a Reply

Your email address will not be published. Required fields are marked *