PDF Converter on Terminal Server

If you are a Delphi developer and have any questions about using our products from Delphi here is the place to post them.
Post Reply
fiachra
Posts: 11
Joined: Wed Jan 28 2004

PDF Converter on Terminal Server

Post by fiachra » Tue Apr 27 2004

My company currently uses 'RAPID PDFWriter' with our Delphi application (FLITE) on a desktop machine. We are developing a Terminal Server version of FLITE and need to have the same 'Save to PDF' functionality available.

I downloaded and installed the trial version of 'Amyuni PDF Converter', and am using calls to cdintf210.dll as follows (note all Amyuni routines and constants start with PDF):

procedure TdlgPrintSettings.InitPDFDriver(var pdf: LongInt; const TempPDFWorkPath, TempPDFFilename: string);
var
pDirectory: PChar;
pFilename: PChar;
rc: LongInt;
ErrorCode: Integer;
Buf: array [Byte] of Char;

begin
pdf := PDFDriverInit(PDFPrinterName);
if pdf <> 0 then
begin
pDirectory := PChar(TempPDFWorkPath);
pFilename := PChar(TempPDFFileName);

rc := PDFLock(pdf, pFilename);
if rc <> 0 then
begin
PDFSetDocFileProps(pdf, pFilename, PDFNoPrompt + PDFUseFileName, pDirectory, pFilename);
PDFEnablePrinter(pdf, PDFLicensedTo, PDFActivationCode);
end
else
begin
ErrorCode := GetLastError;
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, nil, ErrorCode, LOCALE_USER_DEFAULT, Buf, sizeof(Buf), nil);
raise Exception.Create(Buf);
end;
end;
end;

This logic/code works fine on a small test application on the Terminal Server, but refuses to work in any way with FLITE (which is a large memory-intensive application). With FLITE the call to PDFLock returns -1, which I then check with the Windows function, GetLastError, which returns 122. Getting the text for this with the Windows function FormatMessage returns the following error message:

"The data area passed to a system call is too small."

At this point I am completely stumped. I would greatly appreciate any help as soon as possible as we would like to use the Amyuni product, but will need to look elsewhere if we can't find a solution.

Thanks very much in advance,

Fiachra

fiachra
Posts: 11
Joined: Wed Jan 28 2004

Clarification

Post by fiachra » Tue Apr 27 2004

Sorry, just to clarify the call to PDFDriverInit is my own wrapper around the DriverInit routine:

function PDFDriverInit(PrinterName: PChar): LongInt; stdcall; external 'cdintf210.dll' name 'DriverInit';

Joan
Amyuni Team
Posts: 2799
Joined: Wed Sep 11 2002
Contact:

Post by Joan » Fri Apr 30 2004

Hello,

I am not sure i really understand what you mean by: "This logic/code
works fine on a small test application on the Terminal Server, but refuses to work in any way with FLITE (which is a large memory-intensive application)
When you are running your code with FLITE, are you running the code on a server or on a client machine?
Before running your code are you installing the PDF Printer? are you installing it on the server or on the client machine?


Please check that you are installing the PDF Printer on the system before running your code.

The function DriverInit (in your case called PDFDriverInit) return 0 if successfull, I am not sure why you are checking if DriverInit is <> 0 before setting pDirectory and pFileName.

Concerning the Lock function it should return 0 if successfull and an windows error otherwise. One important point about the locking function is that it takes as parameter the printer job name and not the pdf file name. I guess this is what is causing the problem.

You are calling
rc := PDFLock(pdf, pFilename);

is pFilename the same as the print job name you see when printing your document to the Printer?

The lock function should be called as follows:
rc := PDFLock(pdf,DocumentName)

To check what is the document name you can do the following:

- Right click on the PDF Printer or any other physical printer on your system and set 'Pause Printing'
- Print your same document from Delphi to this printer
- double click on the printer and check the print job name (this would be the DocumentName).
- Right click on the printer again and remove 'Pause printing'.

Hope this helps, if not or if you need more details support please feel free to contact our Technical Support Department support@amyuni.com

Have a nice day.

fiachra
Posts: 11
Joined: Wed Jan 28 2004

PDF Converter on Terminal Services

Post by fiachra » Fri Apr 30 2004

Hello Joan,

Thanks for taking the time to reply, I do appreciate it. It looks like I made a bit of a mess of the example I posted - I inadvertently wrote:

...
rc := PDFLock(pdf, pFilename);
if rc <> 0 then
...
although the actual running code is
...
rc := PDFLock(pdf, pFilename);
if rc = 0 then
...

* My understanding of DriverInit is that it will return the Handle for the 'PDF Printer' so the test for <> 0 is correct, I think.

* I am also using the Filename (from PDFLock) as the DocumentName passed to the Printer. I'm actually using QuickReports and I set the value of ReportTitle to the Filename, which is what is displayed as the DocumentName when I pause printing.

* I am testing this application on Windows Server 2003 running Terminal Services. I've narrowed down the problem when I follow these steps:

1. I log into the Server as Administrator.
2. I install 'Amyuni PDF Converter' using PdfDrvDemoEn.exe.
3. I run FLITE.EXE and the 'PDF' functionality works (!)
4. I log out and log back in again as Administrator.
5. I run FLITE.EXE and the 'PDF' functionality no longer works (!!)

Everytime I uninstall and re-install the 'PDF Converter' the application works correctly; when I log in again and try the application, it no longer works.

I would be very thankful for any ideas as to what is going on - I've been at this for weeks and am about to give up on it!

Thanks,

Fiachra

Joan
Amyuni Team
Posts: 2799
Joined: Wed Sep 11 2002
Contact:

Post by Joan » Tue May 04 2004

Hello,

You are not using DriverInit, you are using PDFDriverInit, these are two different functions.

When you log in again, and before trying the application, are you checking if the printer already exists on your system?

If the printer doesn't exist on the system than most probably when running your application PDFDriverInit is not installing the printer and this is mostly due to a rights issue (ie you are logging as a user who doesn't have rights to install the printer).

I would suggest the following:

1 - That you replace PDFDriverInit in your appliation by DriverInit.
2 - That you redo your below test steps to see if it will work.

It seems you were trying for a while to use the PDF Converter before you post your question here, if this is not working, then you don't really need to give up, please send us and e-mail to support@amyuni.com and I am sure our Technical Support Representatives would be able to help you.

Have a nice day 8)

Post Reply