Looking for print driver valid-DEVMODE enforcement and/or pre-job dialog help

Good afternoon, all,

I do printer drivers built on the PostScript OEM driver, and most of the
time we just add some items to the GUI and support on the backend with
psinject. But now a customer requires that we do something different, and
I'm not sure how to do it.

Our print driver supports devices which have a storage feature, so you can
print to a file on the device, either with or without a password. Then when
you show up at the device, you can ask that it print. This is helpful if you
don't want termination notices or checks lying around on the printer.

The old way let the user pick regular / store / secure-store, and this was
just a coupla values in our private DEVMODE, but now the customer wants us
to make a version which ONLY supports secure-store. This means that if the
user has not somehow specified a filename and PIN, we don't print the job.

Most of the DEVMODE routines are built on the notion that if things aren't
right, they roll to a least common denominator, but here it has to be either
"everything is OK" or "we don't print".

Approach #1: restrict this in the UI. This was easy enough - if the user
calls up printing prefs, they can't select an option which is invalid, so
they have to plug in the filename and PIN. But this only works if the pop up
the UI - if they just print from the application without somehow calling
Document Properties, it prints in a wrong mode.

Approach #2: the rendering DLL can easily detect that the mode is not right,
but I have not found a good way to fail a job which tells the user properly.
Just exiting with failure, and letting the user figure it out seems
unreasonable. Even a note in the event log won't fly. I don't think that we
can reasonably do MessageBox() from the rendering DLL anyway - it could be
on a different server, and I think there are terminal-server issues as well.

Approach #3: I found DevQueryPrintEx, which lets us examine a proposed job
and report back - with an error string! - whether we can handle it or not,
but this is designed only to harmonize the job's parameters with the printer
(paper size or other resources). If this returns no-match, then it sits in
the queue until the printer is ready for it. This won't fly.

So now I'm looking in DocumentEvent to skip the normal property sheets and
actually prompt for the information straightaway. Apparently, these printers
will be used in quasi-public areas, and asking for this information every
time seems reasonable. But I'm having a hard time getting to my devmode, and
I just don't know if I'm even going down the right road at all.

Question #1 - what is the best way to reject a job due to improper
parameters in a way that

1) never ever lets wrong-moded jobs print
2) provides the user with reasonable feedback
3) works on local or server-based printers
4) ok to limit to XP/2003

If we detect a problem, we don't have to give the user a chance to fix it
directly - we can just fail the job and tell them to do it again.

When using Microsoft Word's [Print] button, there is a huge amount of UI DLL
chitchat, so for testing I have a small C program which opens the printer,
calls a few GDI ops (draws a line), and closes things. This gives the subset
of operations which I suspect I can count on, and I still see a lot of
activity which smells like I can hook it.

Question #2 - assuming #1 says that I should be hooking DocumentEvent. When
I get the DOCUMENTEVENT_CREATEDCPRE event, the parameter is the big full
DEVMODE, but I can't seem to get to just my piece. There is a public piece
(dmSize) and a private part (dmDriverExtra), but the private part seems to
have the PostScript really-private fields there, and I don't know how to get
to my part. I suspect that I need to cache the last DEVMODE I see, and check
it at the start-page event: if we see a problem, we can abort the job and
notify the user.

I can look in the default DEVMODE in the registry, and I can see our part,
but the only ways to get at them smell terribly nonportable.

Alternatively, at StartDoc, I'll check the DEVMODE to see if the user has
populated all the stuff: if not, then I'll pop up a dialog box to ask them
for it. I'm OK somehow calling the standard UI and asking them to get it
right, but I am just stuck without my OEMDEV.

Can anyone offer any insight?

Steve (Security MVP, and unofficial Printing/Imaging MVP)

P.S. - I have written a few Tech Tips which cover aspects of the printing
system, and they might be helpful to driver writers

Unixwiz.net Tech Tip: Understanding Microsoft's PostScript print drvier
"PSINJECT"
http://www.unixwiz.net/techtips/psinject.html

Unixwiz.net Tech Tip: Managing Win32 Printserver Forms
http://www.unixwiz.net/techtips/winspooler-forms.html


--
Steve Friedl / UNIX Wizard / Microsoft MVP / www.unixwiz.net


.