Re: Default printer being changed with Common dialog
- From: "Galen Somerville" <galen@xxxxxxxxxxxx>
- Date: Sun, 20 Nov 2005 12:17:11 -0800
"Mike Williams" <Mike@xxxxxxxxxxxxxxxxx> wrote in message
news:O3HVWGT7FHA.2692@xxxxxxxxxxxxxxxxxxxxxxx
> "Larry Serflaten" <serflaten@xxxxxxxxxxxxxx> wrote in message
news:e$PSaXS7FHA.476@xxxxxxxxxxxxxxxxxxxxxxx
>
> > What about a fourth method where the default printer is stored at
startup
> > and the user is allowed to change the default printer via the Common
Dialog.
> > The selected device might then be saved as the UserPrinter and the
default
> > printer restored after the dialog exits. Now, ahead of every printing
he might
> > set the Printer to the Users printer, and can then use the printer
object as
> > normal. When done printing, restore the default printer leaving the
default
> > as it was when the app started.
>
> Yes. That is another option. You can just store the details of the
original default, present the user with a standard printer CommonDialog
printer dialogue (with printerDefault set to True to allow him to use
whatever printer he wants and to change its settings as desired) and then
you restore the original printer as the default printer after he has
finished his print job. The snag is that there are too many problems with it
in practice. For example if the current printer is PrinterA and the user
changes it to PrinterB (to do his print job in VB) then all of the changes
he makes to PrinterB will "stick", so that even though PrinterA is restored
as the Windows default printer at the end of the print job, the original
default settings of PrinterB will have been changed and those changes will
have "stuck" (depending on the specific changes and on the version of
Windows). This means that the next person to come along and use PrinterB
will find that the settings he expects it to default to have all been
changed. Also, even on machines with just one printer, the user might
normally have it default to (say) "draft" or "normal" in portrait mode for
all his standard printing and if he uses your VB program to print one
specific job in (say) "best mode on photo glossy paper in landscape with
full bleed edges" then that specific setting will "stick" as the default
(which would cause him to use a lot of extra ink and waste a lot of time the
next time he printed a simple page of text if he just clicked the "print"
button as he was used to doing). I haven't (yet) found a way of restoring
both the default printer *and all of its original default settings*. There
are other problems as well, but it is still definitely an option worth
considering, and there is certainly a way in VB of reliably changing the
Windows default printer to whatever printer you want it to be. It does
actually work in practice. To be honest I haven't really come across a
totally acceptable method of printing in VB (although printing to the
returned CommonDialog hDC property is so far the nearest I have come to it).
By the way, you don't actually need more than one printer to test these
methods. You can check most of the details simply by installing more than
one printer driver. You obviously can't actually print to those drivers if
there isn't a physical printer associated with it, but you can certainly
write VB programs to attempt to make changes and then examine the drivers
and default settings afterwards in Control Panel. This is particularly easy
if you use WinXP, because WinXP includes hundreds of printer drivers on the
XP disk (or on the XP installation "disk" in your hidden partition if that
is how it was originally installed).
>
> The OP has asked for details of what I called "method 3", but first it
might be wise to let him look at the "later posted" offering from Galen
(which is a variation on methods one and two). If he likes that method
(which, incidentally, doesn't actually work in XP) then I can forget all
about writing some more stuff (my fingers are starting to ache now!).
Otherwsie, if Kjell posts again I'll post details of my own preferred
method. As I've said though, I really haven't found a totally acceptable way
of doing this stuff in VB. My own "method 3" works really well under most
circumstances, buit even that method has some limitations. I wonder how
dotnet fares in the "printer" stakes? Hopefully it will have all this stuff
sorted out. (oops! shouldn't have mentioned the name "dotnet"!).
>
> Mike
>
>
Good catch Mike. I develope on 98 and test on both 98 and XP. The built in
Print functions are mainly used to select a different printer. Very few
users need it. Those that do probably don't use the Properties button. I
leave it up to the factory people to wring out the program and this never
came up.
Anyway I modified the PrtDlg test program on my web site
http://home.surewest.net/galen/index.html
Galen
.
- References:
- Re: Default printer being changed with Common dialog
- From: Larry Serflaten
- Re: Default printer being changed with Common dialog
- Prev by Date: Merchandize Security
- Next by Date: Vb6 to .NET Conversion Wizard
- Previous by thread: Re: Default printer being changed with Common dialog
- Next by thread: Re: OT: Is a newsgroup for...
- Index(es):
Relevant Pages
|
