Re: Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- From: "Rick Raisley" <heavymetal-A-T-bellsouth-D-O-Tnet>
- Date: Fri, 6 Mar 2009 08:48:06 -0500
Thanks very much for that thorough analysis, Mike. I will definitely be
looking into doing it that way.
--
Regards,
Rick Raisley
heavymetal-A-T-bellsouth-D-O-T-net
"Mike Williams" <Mike@xxxxxxxxxxxxxxxxx> wrote in message
news:Ow2OlRenJHA.4964@xxxxxxxxxxxxxxxxxxxxxxx
"Rick Raisley" <heavymetal-A-T-bellsouth-D-O-Tnet> wrote in message
news:uWeiRFdnJHA.1168@xxxxxxxxxxxxxxxxxxxxxxx
I always set the default settings back the way they were,
immediately after printing, if I change any.
But it may be too late by then. The best option is not to change the
default settings at all.
The question here is how to change settings. Is the VBPRNDLG.DLL
any good, and preferable to other methods.
The VBprndlg.dll is a wrapper around the API print dialog functions and it
works reasonably well, although like most things it is not perfect. It is
far easier than using the API dialogues for a similar purpose though,
partly because of the messing about you need to do to properly get at the
various memory blocks. The problem with it (and the same problem exists
even when you use the API dialogs directly) is that no matter how much
trouble you go to in order to obtain as many settings as possible you
cannot actually use any user setting from the dialog that the VB Printer
Object cannot "eat", so there are some limitations. However, those same
limitations apply even if you instead use the API printer dialog functions
to perform a similar task.
The vbprndlg.dll is certainly quite useful, and it will not alter the
existing default printer settings, so it is definitely worth using. It is
certainly very much better than the standard CommonDialog Control.
Alternatively, you could "roll your own" dialog using a VB modal Form if
you just want to present a very simple, albeit non standard, dialog to the
user with only a limited number of available settings (using a ListBox and
various option buttons). The main problem with the vbprndlg method and the
alternative API method (a problem which does not apply to the simple "roll
your own" dialog I mentioned, although that of course has its own more
serious limitations), is the fact that they present a printer dialog to
the user and give the user the impression that anything he selects in the
entire dialog will be reflected in his printout, which is simply not the
case. It works for most of the standard settings, but there are various
settings, some of which are special to certain printers, which simply
cannot be "eaten" by the VB Printer Object, and some of which cannot even
be obtained from the dialog itself, at least not in any meaningful way,
whether the VB Printer Object could "eat them" or not.
The only way I personally know of presenting your user with a standard
print dialog in such a way that the printer will respond to all of the
settings the user might make in the dialog, including all of the otherwise
impossible to get at things and all of the "special to printer" things, is
to present the user with a printer dialog using a standard CommonDialog
Control (PrinterDefault set to False and the returnDC flag set) or the
vbrndlg.dll or the API dialog functions themselves and print your stuff to
the returned DC. The only problem with this method of course is that you
would then need to do all your printing using the API drawing and printing
methods instead of the more friendly VB Printer Object methods, which
would mean quite a lot of change to any existing printer code you may have
written and would of course have a bit of a learning curve if you have not
used the API printing and drawing functions before.
If you would prefer to continue to use the VB Printer Object for your
printing then personally I would advise you to stay away from the
CommonDialog Control and to use either the vbprndlg.dll or the alternative
API dialog methods, choosing the vbprndlg.dll for its relative simplicity
if you are happy to package an extra DLL with your project when you deploy
it to other machines and instead choosing the API dialog methods if you
are not prepareed to do that.
Mike
.
- References:
- Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- From: Rick Raisley
- Re: Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- From: Ralph
- Re: Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- From: Saga
- Re: Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- From: Rick Raisley
- Re: Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- From: Mike Williams
- Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- Prev by Date: Re: The Myth of Visual Basic Migration / Upgrade
- Next by Date: Re: global On Error Goto ?
- Previous by thread: Re: Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- Next by thread: RE: Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes
- Index(es):
Relevant Pages
|
