Beiträge von BradR

We’ve run into an odd issue with the wPDF control. We use the InputFileMode=1 to “append” to an existing PDF. We only make use of the the wPDF control’s DC to generate output. The output file created by wPDF is fine until the length of the existing input file exceeds 357 pages. For example, if our program writes 1 page with an existing input PDF containing 357 pages, the resulting output PDF has the expected 358 pages. But if our program writes 1 page with an input PDF having 358 pages, the resulting PDF contains only the first 260 pages of the input PDF. If our program writes 500 pages with an input PDF 357 pages in length, the resulting PDF contains the expected 857 pages. The filesize of the input PDF does not seem to matter, only the page count. I get the same result if the 358 page input PDF is 20MB in size or if it is only 2MB in size. The size of the resulting PDF file does grow as expected, but the pagecount is wrong.

Note that the input file was generated by wPDF as well.

Our software is currently using version 3.77.0.0 of wPDF, testing with version 3.78.0.4 yielded the same results.

Any Ideas?
Thanks

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:

1) Calling ResetDC() will result in an MFC 'hDC not found' VERIFY() when calling wpdfFinalize().

2) 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.

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.

Weird, isn't it?

Hi,

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.

Any thoughts?

We added wPDFControl to our product several years ago. By making use of the DC() function very few source code changes were required. We have had very few problems with it. Our reports output bitmaps by using the Windows StretchDIBits() function. When the total size of all the bitmaps printed reaches about 100MB, an EEDFADE exception occurs. Is this a problem that can be fixed?