[Solved]PDF Converter on Windows 2008 Terminal Server 64 Bit

[IPA]

Hi,

I'm trying to get the PDF-Converter 3.03 running on a Windows 2008 Terminal Server 64-Bit Version but without success.

We’ve an application which uses the converter to convert Word-Documents to PDF-Files.
This application runs well under Windows XP and Windows Vista (both 32-Bit versions).

Due to changes in our network, we would like to use a Terminal Server for our users.

It's here, where my problem begins.
I’ve installed the converter successfully on the terminal server (no errors in the log-file).
When printing to the converter, I get an error-message in the print-queue. It seems that this message is due
to the 64-Bit version of the OS. I’ve found some post in the forum, which says to create my own printer port and to
change the PDF-Converter from port LPT1 to my own port.
After this modification, the error-message in the printer-queue disappeared.

The second, unsolved, problem is that the converter is ignoring the “SetDocFileProps”-Statement in the application.

Code: Select all

Call oCDIPrinter.SetDocFileProps(sLockName, &H1 + &H2 + &H20, "C:\Temp\TestPrinter\", sTempAttPDFFile)

As you can see, the application is not allowed to display the “file name dialog box” (&H1 -> NoPrompt). But when running
the application, it shows always the file name dialog (with the correct path and filename). When canceling this dialog,
we get an error. When confirming or changing the filename, the PDF-File is created as expected.

Is the converter supported to run on Windows 2008 Terminal Server 64 Bit?
If yes, why it shows always the file name dialog?
Does anybody have the same problem or an idea how to solve this!

With best regards,

Ingbert

[David]

Hello

When using locking, the lockname that you provide should be exactly the same name that appears as the document title in the printer dialog i.e. pause the amyuni printer > print from your application to that printer > check the name that appears as the document title in the printer dialog box > The name that appears there is the name you should have used when calling the lock. If the name is different the lock is not used.

In most applications you can set the document title for your document e.g. in PowerBuilder it is the datawindow name

Code: Select all

	//PrinterName is the name of the PDF Converter as it appears
	PDFPrinter = DriverInit(PDFPrinterName)

	//Must use unique Document name 
	ls_document_name = “test”
 	
                //assign document name to datawindow
	dw_list.Object.DataWindow.Print.DocumentName = ls_document_name

	//apply the lock
	Lock(PDFPrinter, ls_document_name)  
	
	//set the printer properties
	SetDocFileProps(PDFPrinter , ls_document_name, NoPrompt + UseFileName , "", "c:\temp\sample.pdf") 

	EnablePrinter(PDFPrinter,LicensedTo,ActivationCode)
 
	//Print to the datawindow
	dw_page1.Object.Datawindow.Printer = PDFPrinterName
	w_app_powerbuilder_rpt.dw_page1.Print()


	//unlock process.. if errors occurs
	Unlock(pdf, ls_document_name, 180000) 

Hope that helps?
David

[IPA]

Hello David,

thank you for your answer.

My problem is not the locking-system (it's working as expected on other systems).

After some hours of research and system-analyze with procmon from Sysinternals, I've found the solution for my problem.

In the logs, generated by procmon, I see that the converter writes the lock- and job-info’s in the registry.
In my case, its writes the info in a subkey named DOC_Test.doc under HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\0001\Software\PrinterName\Jobs or Locks
The information’s stored under this key are the same as in HKCC\Software\PrinterName\Jobs or Locks.
After writing the info’s in the registry the system continues to thread the print-job. After a while, the converter is accessing the registry for reading the job-info saved in the above keys.
But this time, and this is very strange, it seeks for the job info for DOC_Test. The converted has dropped the file-extension.
When now configuring the windows-explorer to display the known file-extension everything works as expected.

I was able to reproduce this behavior on a Windows Vista system where we had never a problem
It seems that the converter takes cares of the settings from the windows-explorer to show or not to show the known file-extensions.

Very, very strange!

With best regards,

Ingbert

[Joan]

Hello,

I set this issue to solved as you have solved it yourself.

You are right, somehow, but it’s not the Converter’s issue.
The converter follows the name of the print job supplied by windows.

On the 32 bit machines, the job name was DOC_Test.doc but on your 64 bit machine, it is actually DOC_Test so, it is not us changing it, you need to change your code to supply the correct job Name to the SetdocFileProps. Your solution will also work perfectly.

Best Regards,