When calling Lock are you suppose to use the title of the file being converted into a PDF (i.e. the word document) or are you suppose to use the title of the PDF being created?
I have seen mixed indications among the forum posts and would like clarification.
Lock Title
-
DarylBlowes
- Posts: 8
- Joined: Sun Mar 12 2006
Lock Title
How are you suppose to find out what the title in the spooler will be? Applications use different conventions ... some will use file name with extension, some without. Some use title of main window. Browsers use URL.
How are we suppose to create a reliable locking system when we are batching files of different types? The types are not always known and can be any registered program.
How are we suppose to create a reliable locking system when we are batching files of different types? The types are not always known and can be any registered program.
-
DarylBlowes
- Posts: 8
- Joined: Sun Mar 12 2006
Lock Title
Got answer from phone conversation:
The only way to link the printer input stream from an application is the Title which is displayed in the print queue. Because each application prints using a different name or title, there is no reliable way to obtain the title unless you know the application and how it formulates it. In my case I am using BatchConvert on many different unkown file types so this won't work.
The problem is not the driver... it is the time between setting the global DefaultFileName/Options and the time that the driver actually receives input from the printing application. During this period another application could change those settings before the application starts spilling its print data.
To get around this they implemented the Lock functions which use the title. Using the SetDocFileProps function then allows you to link the default file name and options to the job, but again it uses the title to link everything together. When the printing starts, the driver knows what lock and fileprops to use by the Title. Once printing starts the lock for that title is removed by the driver routine.
None of this is useful if you don't know the title of the print output... so as you can see in their tech note #01 in the ASP sample they use a global lock like Application.Lock. This will prevent any process from continuing while it prints, thereby forcing everything to happen in serial. This will prevent concurrent printing, but will prevent the default options from being overwritten before print data is received.
For non-ASP code I will probably implement a global mutex and somehow link it to the Job ID. This will be done using the events because a Job can start from my application (as a batch) or externally from any application by the user if they do a print to... then as soon as the first page has printed for my job I will unlock it globally.
I will post here if it works.
Thanks to Amyuni tech support for all your help.
The only way to link the printer input stream from an application is the Title which is displayed in the print queue. Because each application prints using a different name or title, there is no reliable way to obtain the title unless you know the application and how it formulates it. In my case I am using BatchConvert on many different unkown file types so this won't work.
The problem is not the driver... it is the time between setting the global DefaultFileName/Options and the time that the driver actually receives input from the printing application. During this period another application could change those settings before the application starts spilling its print data.
To get around this they implemented the Lock functions which use the title. Using the SetDocFileProps function then allows you to link the default file name and options to the job, but again it uses the title to link everything together. When the printing starts, the driver knows what lock and fileprops to use by the Title. Once printing starts the lock for that title is removed by the driver routine.
None of this is useful if you don't know the title of the print output... so as you can see in their tech note #01 in the ASP sample they use a global lock like Application.Lock. This will prevent any process from continuing while it prints, thereby forcing everything to happen in serial. This will prevent concurrent printing, but will prevent the default options from being overwritten before print data is received.
For non-ASP code I will probably implement a global mutex and somehow link it to the Job ID. This will be done using the events because a Job can start from my application (as a batch) or externally from any application by the user if they do a print to... then as soon as the first page has printed for my job I will unlock it globally.
I will post here if it works.
Thanks to Amyuni tech support for all your help.
Hello,
This is a general note about licenses.
I am not sure which version of the PDF Converter you are planning to use, but please note that with the Developer license does not enable you to allow users to print directly to the PDF Printer from other applications than the one you are developping.
Thanks.
This is a general note about licenses.
I am not sure which version of the PDF Converter you are planning to use, but please note that with the Developer license does not enable you to allow users to print directly to the PDF Printer from other applications than the one you are developping.
Thanks.