Not concatenating

sgowens · Post by **sgowens** » Mon Apr 24 2006

Have a client that has a 64-bit Intel processor (not sure if part of problem though.) I use the activex and driverinit to create pdf and route all print jobs to it. The pdf only contains the first document I send to it. My same code works on hundreds of computers as is. I deliver the necessary files to the system32 directory (there is a system32 directory but windows seems to put everything in a systemwow32 ??. And the cdintf250.dll is registered there. Any thoughts?

Sean

Joan · Post by **Joan** » Tue Apr 25 2006

Hello,

If you are using a version of the PDF Converter that supports 64-bits than this should not be a problem.

You can specify explicitly where the PDF file will be generated and what will be its name by using DefaultFileName() and by adding UseFileName (=2) to your call of FileNameOptionsEx().

If you want the newly generated PDF files to be concatenated to an existing PDF you need to also add Concatenate (=4) to FileNameOptionsEx().

Hope this helps.

sgowens · Post by **sgowens** » Tue Apr 25 2006

That's exactly what I've been doing for years and it works on all but on this 64-bit 2003 server (which is used as a Terminal server-I have many terminal server clients using the pdf stuff and it's all working). I see that the first page/report gets sent to the pdf, and subsequent reports go through the driver because as I have the Windows printer screen open while I'm running the code I can see it being sent out, I just don't know where it ends up. It seems like if the concatenate wasn't working for some reason, perhaps it would just keep overwriting the pdf file and I should end up with the last page/report in the pdf document, not the first (hope this makes sense.)

Sean

Joan · Post by **Joan** » Tue Apr 25 2006

Hello,

Which version of the PDF Converter are you using?

sgowens · Post by **sgowens** » Tue Apr 25 2006

2.50f

Post by **Jose** » Wed Apr 26 2006

Hello,

Under windows 64bit installations of the PDF Converter, the internal process used for appending PDF documents is slightly different from the process used under windows 32bit installations.

In windows 64bit when the append (concatenation) option is used, the PDF Converter internally generates a vbs script in the logged in userâ€™s temp directory. The script calls the registered Cdintf250.dll and performs the appending option. The vbs script is then deleted when the process is finished. We suspect that in your case the vbs script is not being created.

In order to verify this, I suggest that run your application and verify if a vbs script is created and deleted in the directory below:
C:\Documents and Settings\<User Name>\Local Settings\Temp

Also, some anti virus applications restrict the execution of vsb scripts. If you an anti virus software running, then temporally stop this application and verify your results.

Hope this helps?

sgowens · Post by **sgowens** » Wed Apr 26 2006

There are certainly files being created there. I emptied out the directory, then ran the procedure in our software to produce the PDF stuff and some temp files ended up there as well as a folder called Adobe with stuff inside of it. I used filemon to track what was going on but it too hard to tell what's going on in the log. In this instance there should be 4 pages (each page is actually a separate report). I end up with a pdf that contains the first page (report) and not the rest.

sgowens · Post by **sgowens** » Thu Apr 27 2006

Filemon shows the wscript is trying to run but gives a 'buffer overflow' error, which probably causes problems from that point forward. I can manually run wscript though, and there is no antivirus program getting in the way on this server.

Post by **Jose** » Mon May 01 2006

Hello,

Can you send the Filemon logfile which shows the 'buffer overflow' error to support@amyuni.com? We'll let you know what we find.

Thanks