The original problem seems to be resolved by using WPPDF_ReferenceDC instead of WPPDF_UsePrinterDC. One strange thing is that assigning any value with WPPDF_UsePrinterDC resolves the alignment problems, which led to the question 'am I supposed to pass a hDC to a function that takes an integer, or am I setting a flag?'
When using the version 2 DLL, we basically used our printer output code without any changes. With version 3, two things came up:
Calling ResetDC() will result in an MFC 'hDC not found' VERIFY() when calling wpdfFinalize().
It seems to be necessary to reset the WPPDF_ReferenceDC to 0 before calling wpdfEndDoc() or else the ReferenceDC is deleted. Another EEDFADE will result.
thats wierd. It sees that under that circumstaces it is not possible to get a DC on the printer anymore. But actually I do not know what to do for this case, other than not use that DC.
I have finally figured out how to reproduce this problem:
Use Remote Desktop on a Windows7 workstation to connect to a Vista workstation (neither machine needs to have the dll loaded). End the remote session. Now locally log back onto Vista. The Vista workstation will now throw an EEDFADE exception whenever wpdfSetIProp(WPPDF_UsePrinterDC) is called. The Vista workstation must be restarted before it will work again.
I'm using the 3.77.0.0 dll. Out in the field, some of our customers are receiving an EEDFADE exception each time wpdfSetIprop() is called with the WPPDF_UsePrinterDC index. If we don't use this option, alignment issues result.
Most, but not all, of the users receiving the exception are using Citrix clients.
This exception has only occured on one machine in-house. The exception occured continuously until the machine was rebooted. Afterwards the problem could not be reproduced.
The dll is loaded prior to each use, and unloaded afterwards.
