
EnumPrinters, DocumentProperties & default DevModes
Ant!
I reread you post carefully again :)))
In your shoes, I would check the drivers for the printer, if there are any
updates etc. from HP. As well as squirt of a small mail to their tech
support with the question.
But your approach seems reasonable from a general standpoint - although it's
not funny to program around what might be a bug in someone elses component
:-( But your solution should cater for all similar cases in the future as
well - so why not stick to it?
Johan Rosengren
Responsable Informatique
PACTA S.A.
Quote:
> Hi Johan,
> it's not so much reading the registry that's the issue - what's
> happeneing is the first time I detetct the pinfo structure has no
> devmode, I build a default one with DocumentProperties and that process
> (usually) updates the reg, so the next time I get the pinfo it DOES have
> a devmode.
> Is there another way of ensuring a devmode is always available other
> than rebuiling it every time the pinfo says there isn't one?
> Cheers
> Ant
> >Ant!
> >Depending on reading the Registry directly in this fashion is always a
risky
> >business - for the reasons you just have discovered. I would definitely
> >contact HP in this case.
> >Johan Rosengren
> >Responsable Informatique
> >PACTA S.A.
> >> I have some code which provides a "print dialog" much like the common
> >> one but greatly simplified.
> >> In the past (it's old code) we noticed that some printers did not have
a
> >> DEVMODE structure in the PRINTER_INFO_2 structure that was obtained
from
> >> the EnumPrinters call, so in this case we call DocumentProperties to
> >> generate a default DEVMODE - this event cause the "Default DevMode"
> >> entry in the registry under
> >> HKLM\System\CurrentControlSet\Control\Print\Printer\<printername> to be
> >> filled in with valid data and from that point on subsequent
EnumPrinters
> >> calls always returned printer info structures WITH valid DEVMODES.
> >> What we've now found is that certain new HP printers (DJ 840C for one)
> >> do not fill in the registry entry after the DocumentProperties call.
> >> I can't find any documentation about this reg entry or this behaviour
so
> >> I don't know if it's supposed to happen or this is a printer driver bug
> >> or what.
> >> However, if you just bring up the printer's Properties dialog from
> >> control panel/printers and OK it, the reg entry does get updated and
> >> everything works.
> >> Can anyone point me in any direction that may lead to a better
> >> understanding of this issue?
> >> Many thanks
> >> Ant