PDF XChange Forum

PXC::IPXCControlExPtr m_pFactory = PXC::IPXCControlExPtr(__uuidof(PXC::CPXCControlEx));

if(m_pFactory == NULL)
return FALSE;

CString printer_name = "PDF-XChange 4.0";

PXC::IPXCPrinterPtr m_pPrinter = m_pFactory->Printer[L"", (LPCTSTR)printer_name, L"<reg code>", L"<dev code>"];


if we use above code in our application at start-up and use it to export out data to pdf document, temporary printer object will be created as "pdf-xchange 4.0(1)" and used instead of "pdf-xchange 4.0" that is already installed.

the problem is, when a user changes some printer properties of "pdf-xchange 4.0" (ex: turn off graphics compression) that change will not affect our pdf export program because in our system this temporary "pdf-xchange 4.0(1)" gets created/used.

is there any way to grab existing pdf-xchange printer instead of creating new one every time?

No, there is no way to grab the existing printer.
However the solution is simple - name your printer not as "PDF-XChange 4.0". but, say, "My cool printer"

The issue we're having is not about "PDF-Xchange 4.0(1)' being created.

When we were using PDF-XChange 3.0 we didn't have this problem of duplicate printer being added every time a user does pdf export (and removed afterwards). so a user could easily change printer properties of pdf-xchange from control panel to change quality of pdf document being created.

After we've upgraded pdf-xchange to version 4.0, now pdf export is done by using this temporary printer driver, and unless we programatically modify printer preferences of pdf-xchange, users don't have a way to change pdf preferences.

You will need to set up your app to collect and use preferences you (your user) designate - so you could create a small config or text file that your user maintained and you loaded programmatically by default at the time the printer is instantiated.

The whole point of using an SDK is to give you the ability to control the output as you require rather than you having to use options prescribed by us - also the licensing of the SDK is designed specifically so that your user does not have the ability to output to the driver direct or control via the end user interface - there are also numerous technical benefits of the current method of creating a new printer for each job so the settings can be prescribed much more reliably for specifics for each job - which could not be done if each job went to the same printer in a serial fashion.

For example pages from 1 job could in problematic or time consuming print jobs end up being inserted into another different job - hence the reason for the new asynchronus multi printer option - the cost being you have to preset output options.

But there is nothing to stop you within your app designing a small settings edit/change table that you inherit by default if required that your user can maintain through your own designed interface.

thanks.
just to be clear, there is no way for this new temp instance of pdf-xchange(1) to be initiated with the preference settings copied from the original pdf-xchange 4.0, and we need to read from some other config file that a user can modify, set preferences for the new instance of pdf-xchange programatically at the start of our app is this correct?

Hello oceanpark,

The stand alone driver should be storing it's settings in a profile, and the settings for the currently active one could be found here:
HKEY_CURRENT_USER\Software\Tracker Software\PDF-XChange 4.0\Drivers\PDF-XChange 4.0\Profiles\Current

So you could read data from those registry entries - and update the instance you create accordingly. Please note though that only settings that differ from the defaults would be added to the registry - so the list of things you will find in the profile is not static.

Best,
Stefan