Re: Print Processor: Determining Spool File Name (XP/2K)

From: Jim Jacobson (anonymous_at_discussions.microsoft.com)
Date: 02/10/04 

Date: Mon, 9 Feb 2004 19:26:05 -0800

I agree with you that the print processor needs to be rearchitected. Unfortunately I don't have the ability to do that at this point because there are components that are out of my control at the moment. So yes, I am in need of a workaround until such time as a rearchitecture is possible.

I tried what you suggested. Unfortunately, following your suggestion did not help. The spool files still are named as they had been before (the Windows XP format, rather than Windows 2000 style), even though they show up in the newly supplied directory (confirmation that the spooler recognized the change). I restarted the spooler and also restarted the computer to no avail. Is there anything else that I should be looking for?
     
     ----- Ashwin [MS] wrote: -----
     
     Your print processor architecture is broken because it relies so much on the
     spool file name. There should be no necessity for the print processor to
     have access to the spool file name. I strongly suggest that you consider
     re-architecting your print processor to eliminate this tight coupling.
     
     In any case, considering that you need a workaround for this issue now, you
     can change the spool file naming mechanism on XP to revert to the W2K scheme
     that is based on the job id. In order to do this, you need to change the
     default spool directory to something other than the default. You can supply
     any directory you want...it just can't be the default. The reg key to change
     is HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print\SpoolDirectory.
     
     Hope this helps.
     
     --
     - Ashwin
     
     Microsoft Printing, Imaging and Fax Team
     This posting is provided "AS IS" with no warranties, and confers no rights.
     
     "Jim Jacobson" <anonymous@discussions.microsoft.com> wrote in message
     news:4EF9D6A1-4445-48AC-9DDF-36C4C0E44243@microsoft.com...
> I have a print processor that worked great in Windows 2000, but broke in
     Windows XP, and I am trying to get it working. The print processor depends
     on knowing the name of the spool file that is created (I am using EMF, not
     raw), because I process the EMF data directly from the spool file.
>> When I first wrote the print processor I saw the PRINTPROCESSOROPENDATA
     parameter of OpenPrintProcessor() and said, "Great! I'll use the
     pOutputFile value in that structure to get the file name." The problem is,
     it is never supplied. Anytime I checked the value in the structure that was
     pointed to by the input parameter, it was empty.
>> In Windows 2000 (and NT), though, I noticed that the spool file (located
     in the spool file directory, which I can get from the registry) had the form
     XXXXX.spl where XXXXX is a zero padded number that always corresponded to
     the JobId, which I COULD get from PRINTPROCESSOROPENDATA. Obviously it was
     not a robust solution, but it was a solution that worked fine.
>> So along comes Windows XP and the print processor broke, because XP
     doesn't use the same form for the spool file name. It uses FPXXXXX.spl,
     which is the same form with a prepended literal string "FP". I figured I
     could deal with that just fine in one print processor, by just looking for
     either the file with the FP in front or not. So I tried it, and to my
     dismay found out that the number XXXXX in Windows XP does not correspond to
     the JobId anymore!
>> I thought perhaps I could use the spool file handle returned by
     GdiGetSpoolFileHandle() along with GetFileInformationByHandle() to find
     unique information about the file (the file index, creation date, etc.) and
     search for the matching file in the spool file directory. Unfortunately,
     the spool file handle is not a file handle.
>> So, does anybody know a way I can reliably retrieve the spool file name
     from a print processor (preferably in OpenPrintProcessor) that will work for
     NT, 2000 and XP?
>> And yes, I do need access to the actual spool file, or the whole
     architecture that this print processor is a part of breaks.
     
     
     

Relevant Pages

  • Re: Print Processor: Determining Spool File Name (XP/2K)
    ... Your print processor architecture is broken because it relies so much on the ... have access to the spool file name. ... Windows XP, and I am trying to get it working. ... search for the matching file in the spool file directory. ...
    (microsoft.public.development.device.drivers)
  • Re: Print Processor: Determining Spool File Name (XP/2K)
    ... Your print processor architecture is broken because it relies so much on the ... have access to the spool file name. ... > I have a print processor that worked great in Windows 2000, but broke in Windows XP, and I am trying to get it working. ... > I thought perhaps I could use the spool file handle returned by GdiGetSpoolFileHandlealong with GetFileInformationByHandleto find unique information about the file and search for the matching file in the spool file directory. ...
    (microsoft.public.development.device.drivers)
  • Re: spool file name
    ... The print spooler is designed to be built from components that can be ... I have not written a print processor or print monitor myself, ... If it is a network printer, is the spool file on the print server? ...
    (microsoft.public.windowsxp.print_fax)
  • Re: spool file name
    ... What do you think about making it a print processor or print monitor? ... returned by EnumJobs or GetJob. ... If it is a network printer, is the spool file on the print server? ...
    (microsoft.public.windowsxp.print_fax)
  • Re: Print Processor: Determining Spool File Name (XP/2K)
    ... spool file naming convention. ... > Your print processor architecture is broken because it relies so much on the ... There should be no necessity for the print processor to ... > search for the matching file in the spool file directory. ...
    (microsoft.public.development.device.drivers)