Agreed. Right now, the update process is:

1.  Return to computer and realize the PDF process hasn't started because an update is available.
2. Click OK to open page to download new version.
3. Download the program installer.
4. Launch the installer.
5. Get the error message that you have to uninstall the thing first.
6. Go to the Uninstall interface in Windows and uninstall.
7. Read the text and click Yes then No after squinting and reading.
8. Finish uninstallation.
9. Rerun installer.
10. Install.

Look at what they do for cups-pdf on Linux: 

1. Open your update manager
2. Click Check for Updates
3. Click Install Updates

There is a setting for how often to check for updates in program options under 'General settings 2' (sorry, I'm using non-English version, not sure how it actually is in English). Does this not help? I have it set to 'Never' and I've never seen the new version notification on my PC.

For our internal use, I put up an update.txt file with the version number we have deployed to our own website and using SquidGuard I redirect all requests for  http://www.pdfforge.org/products/pdfcreator/update.txt to http://oursite.com/pdfcreator/update.txt. This solves the problem even for these computers where this setting is accidentally left on. Our users don't have administrator rights on their PCs, so they can't do anything about the message anyway.

I use PDFCreator via COM and it would be really handy to have an option in the COM interface to turn the update checker off. Or maybe there already is one and I'm too dumb to find it.

Hi jsaa,

Actually, I just ran into this issue myself. I did some poking around and found out how to set the update interval via the COM interface.

 Here's some quick VBA code for how to do it that I use to programmatically set the update interval to never:

Sub SetUpdateFreq()
    Dim pdC As Object

    Set pdC = CreateObject("PDFCreator.clsPDFCreator")
    
    pdC.cStart

    'Update intervals: 0 = never, 1 = once a day, 2 = once a week, 3 = once a month
    pdC.cOption("UpdateInterval") = 0
    pdC.cSaveOptions
   
    pdC.cClose
    
    Set pdC = Nothing
End Sub

We have pdfcreator installed in a TS environment, which is having issues with the update prompt.

We can disable it, but only on a per user basis.  Which is a pain. 

What we'd love is a registry edit that stopped it looking, at all.

ANother Technician

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\PDFCreator\Program]
"UpdateInterval"="0"

Copy the above text and save it to a .txt file, then change the file association from ".txt" to ".reg" mannually, double click the .reg file, click "Yes" , this will make your installed PDFCreator no longer check for update.
 

Hope this will help. :)

That works for individual users - but I have ~7,000 users who might log on to the server.

Doing this for each one would be a problem; I could change the log on scripts to include this, but this would involve a non-trivial amount of change management paperwork.

Is there a reg hack that can be used on a per machine basis, not per user?

I just use PDFCreator on my personal PC. I don't have such large scale corporate environment software deployment experience.

Some previous posts in this forum have long hoped for a .msi installer that can do such job.

If you want to automate the PDFCreator deployment process on a corporate environment, a .msi installer package is the best solution. You may need installaware or installshield to build a .msi installer package.

The problem is when you have pdfcreator installed on a server - a couple of dozen/hundred/thousand users can log on... changing each users registry by hand would be a nightmare.

Better to just change a server setting, if possible.

Read the help file please -> settings.

or use

[HKEY_LOCAL_MACHINE\Software\PDFCreator\Program]
"UpdateInterval"="0"

Thanks for that.

I'm now going to hit the technical specialists with a clue-by-four - it's their fault that it's the standard install is used on the 60-odd TS servers, rather then the server install.

Looks like they're going to spend a weekend re-installing this on the farm. 

Oh well :)

On a terminal server farm you must use the standard instalation!!! Set the HKLM setting manually.

And HKLM will overwide HKCU?

HKLM has higher priority than HKCU.

This registry key under HKLM no longer works for version 1.2.0 (this morning I was prompted for 1.2.1).

I have added the key under HKCU instead. Is this going to be enough?

Thanks.