API PrntDlg function 
Author Message
 API PrntDlg function

Hi Mike Williams
I have been reading old posts on API Printing and in a post
from November 2008 Mike said that there was a good but long
example on the MSDN site which had a problem if the printer name
was longer than 30 chars. As I do not have this problem I wonder if you
could point me in the  right direction as I want to convert my printing from
CommonDialog to API and a good example with code I can paste will
be helpful.

Thanks in anticipation

Ron



Sat, 02 Jul 2011 18:54:01 GMT  
 API PrntDlg function
hi Ron,

There's this wrapper of the PrintDlg function:
http://support.microsoft.com/kb/322710


Quote:
> Hi Mike Williams
> I have been reading old posts on API Printing and in a post
> from November 2008 Mike said that there was a good but long
> example on the MSDN site which had a problem if the printer name
> was longer than 30 chars. As I do not have this problem I wonder if you
> could point me in the  right direction as I want to convert my printing
> from
> CommonDialog to API and a good example with code I can paste will
> be helpful.

> Thanks in anticipation

> Ron



Sat, 02 Jul 2011 20:13:12 GMT  
 API PrntDlg function
Hi Bill
Thanks for your help, I had picked up this DLL from the same
article by Mike and was going to ask if I need to include that in
my project. What do you think?

Ron

Quote:

> hi Ron,

> There's this wrapper of the PrintDlg function:
> http://support.microsoft.com/kb/322710



> > Hi Mike Williams
> > I have been reading old posts on API Printing and in a post
> > from November 2008 Mike said that there was a good but long
> > example on the MSDN site which had a problem if the printer name
> > was longer than 30 chars. As I do not have this problem I wonder if you
> > could point me in the  right direction as I want to convert my printing
> > from
> > CommonDialog to API and a good example with code I can paste will
> > be helpful.

> > Thanks in anticipation

> > Ron



Sat, 02 Jul 2011 21:30:00 GMT  
 API PrntDlg function

Quote:
> Hi Mike Williams. I have been reading old posts on API
> Printing and in a post from November 2008 Mike said
> that there was a good but long example on the MSDN
> site which had a problem if the printer name was longer
> than 30 chars. As I do not have this problem I wonder
> if you could point me in the  right direction . . .

The 30 character printer name restriction referred to the dialog code at the
MSDN site I mentioned, but there is also a library (DLL) which performs a
similar task and which does not have that restriction. If you are happy
registering and using a DLL then you'll find it, together with some sample
code, at the following link:

http://support.microsoft.com/kb/322710

Mike



Sat, 02 Jul 2011 21:45:07 GMT  
 API PrntDlg function
Hi Ron,

Yep you need to include it and register it with RegSvr32.  IIRC it's a C++
wrapper for the PrintDlgEx API.


Quote:
> Hi Bill
> Thanks for your help, I had picked up this DLL from the same
> article by Mike and was going to ask if I need to include that in
> my project. What do you think?

> Ron


>> hi Ron,

>> There's this wrapper of the PrintDlg function:
>> http://support.microsoft.com/kb/322710



>> > Hi Mike Williams
>> > I have been reading old posts on API Printing and in a post
>> > from November 2008 Mike said that there was a good but long
>> > example on the MSDN site which had a problem if the printer name
>> > was longer than 30 chars. As I do not have this problem I wonder if you
>> > could point me in the  right direction as I want to convert my printing
>> > from
>> > CommonDialog to API and a good example with code I can paste will
>> > be helpful.

>> > Thanks in anticipation

>> > Ron



Sat, 02 Jul 2011 21:41:15 GMT  
 API PrntDlg function
Hi Micheal
Thanks for that I had downloaded the DLL and put in the correct folder
and I have created the little program as instructed and I mostly understand
how that works.
Is that all I have to do, I thought I would have to also use some API's I am
somewhat confussed, can you put me right please.

Thanks in anticipation

Ron

Quote:



> > Hi Mike Williams. I have been reading old posts on API
> > Printing and in a post from November 2008 Mike said
> > that there was a good but long example on the MSDN
> > site which had a problem if the printer name was longer
> > than 30 chars. As I do not have this problem I wonder
> > if you could point me in the  right direction . . .

> The 30 character printer name restriction referred to the dialog code at the
> MSDN site I mentioned, but there is also a library (DLL) which performs a
> similar task and which does not have that restriction. If you are happy
> registering and using a DLL then you'll find it, together with some sample
> code, at the following link:

> http://support.microsoft.com/kb/322710

> Mike



Sun, 03 Jul 2011 00:16:17 GMT  
 API PrntDlg function

Quote:
> I downloaded the DLL [vbprndlg] and put in the correct folder
> and I have created the little program as instructed and I mostly
> understand how that works. Is that all I have to do

You're supposed to also follow the instructions to register the DLL using
Regsvr32. Have you done that, and did you get a "success" message? When you
have done that, and in order to use the dll, you should start a new VB
project (one Form containing a Command Button) and use the Project /
References menu to set a reference to Microsoft VB Printer Dialog, which you
should find in the scrollable list if you registered the DLL properly. Then
you can paste the example code from the page where you downloaded the dll
into the Command Button's Click event and then run your code and click the
button. Does the example VB code run okay on your machine, and does it show
a printer dialog and write some results to the Debug window when you click
the Command Button?

Quote:
> I thought I would have to also use some API's I am
> somewhat confussed, can you put me right please [1]

There was once a rather large block of code on the MSDN pages which used
various API functions to display a printer dialog and it included some code
allowing you to set up various start parameters for the dialog and to read
the results after your user had made his selections in it. The vbprndlg.dll
which you downloaded is an alternative way of doing the same thing. It does
more or less the same job without requiring you to use any API functions.
The code as it stands (the code example at the link where you just
downloaded the DLL) does not actually print anything, it merely sets the VB
Printer Object to the printer chosen in the dialog and transfers various
user settings (orientation, copies, etc) to it. In order to actually print
anything to the chosen printer you still need to use the VB Printer Object
printing methods in the normal way.

Quote:
> I thought I would have to also use some API's [2]

Just to make sure we're both talking about the same thing, in your original
post in this thread you said that you wanted to convert your printing from
the CommonDialog to the API. Did you mean that you wanted to use an API
printer dialog instead of the CommonDialog Control's printer dialog, so that
you could eliminate some of the shortcomings of the CommonDialog Control,
but that you wanted to still do your actual printing using the VB Printer
Object? Or did you perhaps mean that you wanted to do everything concerning
your printing, including showing the dialog and perfoming the actual print
job itself, using the various API methods and without using the VB Printer
Object at all?

Mike



Sun, 03 Jul 2011 01:19:47 GMT  
 API PrntDlg function

Hi Mike Williams
In reply to your helpful post the truthful answer is I do not know,
as I have said before I am a self taught newbie.
The post was because on a previous post it was said "I do not use Common
Dialog I use API's" so thats why I posted this question.

All of my printing has been created from information posted by you in
examples etc. I want to improve my project should I move on to to all API's?
if yes I will have to get a book.

Lay it on the line I will not be offended.

Ron

Quote:


> > I downloaded the DLL [vbprndlg] and put in the correct folder
> > and I have created the little program as instructed and I mostly
> > understand how that works. Is that all I have to do

> You're supposed to also follow the instructions to register the DLL using
> Regsvr32. Have you done that, and did you get a "success" message? When you
> have done that, and in order to use the dll, you should start a new VB
> project (one Form containing a Command Button) and use the Project /
> References menu to set a reference to Microsoft VB Printer Dialog, which you
> should find in the scrollable list if you registered the DLL properly. Then
> you can paste the example code from the page where you downloaded the dll
> into the Command Button's Click event and then run your code and click the
> button. Does the example VB code run okay on your machine, and does it show
> a printer dialog and write some results to the Debug window when you click
> the Command Button?

> > I thought I would have to also use some API's I am
> > somewhat confussed, can you put me right please [1]

> There was once a rather large block of code on the MSDN pages which used
> various API functions to display a printer dialog and it included some code
> allowing you to set up various start parameters for the dialog and to read
> the results after your user had made his selections in it. The vbprndlg.dll
> which you downloaded is an alternative way of doing the same thing. It does
> more or less the same job without requiring you to use any API functions.
> The code as it stands (the code example at the link where you just
> downloaded the DLL) does not actually print anything, it merely sets the VB
> Printer Object to the printer chosen in the dialog and transfers various
> user settings (orientation, copies, etc) to it. In order to actually print
> anything to the chosen printer you still need to use the VB Printer Object
> printing methods in the normal way.

> > I thought I would have to also use some API's [2]

> Just to make sure we're both talking about the same thing, in your original
> post in this thread you said that you wanted to convert your printing from
> the CommonDialog to the API. Did you mean that you wanted to use an API
> printer dialog instead of the CommonDialog Control's printer dialog, so that
> you could eliminate some of the shortcomings of the CommonDialog Control,
> but that you wanted to still do your actual printing using the VB Printer
> Object? Or did you perhaps mean that you wanted to do everything concerning
> your printing, including showing the dialog and perfoming the actual print
> job itself, using the various API methods and without using the VB Printer
> Object at all?

> Mike



Sat, 09 Jul 2011 17:32:00 GMT  
 API PrntDlg function

Quote:
> In reply to your helpful post the truthful answer is
> I do not know, as I have said before I am a self
> taught newbie. The post was because on a previous
> post it was said "I do not use Common Dialog I use
> API's" so thats why I posted this question.

I do remember making a statement along those lines some time ago but I can't
remember in what context it was made, although I think I was probably
referring to the fact that the standard VB CommonDialog Control has a number
of limitations and that I therefore use an API printer dialog instead, which
is much more flexible, although I do sometimes also use the API (GDI)
methods insteads of the VB Printer Object methods to actually draw the
printed output.

Quote:
> All of my printing has been created from information
> posted by you in examples etc. I want to improve my
> project should I move on to to all API's? if yes I will
> have to get a book. Lay it on the line I will not be
> offended.

Regarding whether to use the VB methods or the API for printing there are
two separate things to consider. The first thing to consider is the method
of showing the printer dialog, which can be done in a number of different
ways, for example:

1. The VB CommonDialog Control
2. The Microsoft vbprndlg.DLL (which is a wrapper around the API dialog
functions)
3. The API printer dialog functions themselves.

Once you have shown the dialog and the user has made his selections in it
(the printer he wishes to use and various printer settings such as
orientation, etc) then you can then use the returned results to set up the
VB Printer object accordingly and print using the Printer Object's native
drawing methods (which will work properly only for methods 2 and 3 above) or
you can alternatively hold onto the returned hDC and print directly to that
hDC using the API drawing methods (which will work properly for all three
methods above).

The second thing to consider is the actual printing itself (the drawing of
stuff onto the page) which can also be done in a number of different ways,
including (but not limited to):

1. Print to the VB Printer Object using native VB drawing methods.
2. Print to the VB Printer Object using API (GDI) drawing methods.
3. Print to a hDC returned by the CommonDialog Control using GDI drawing
methods.
4. Print to a hDC returned by the vbprndlg.DLL using GDI drawing methods.

These things (and others) can be 'mixed and matched' in all sorts of
different ways, and you need to consider the various advantages and the
various limitations of all of them, which is far too much for me to go into
here. Personally I would suggest that you use an API dialog (rather than the
CommonDialog Control) because the CommonDialog Control is not much use if
you want to set up some initial default printer settings and also not much
use if you are printing using the VB Printer Object's native drawing methods
(although it is fine in the latter respect if you are drawing your print
output using the API drawing methods), whereas the API dialogs are
reasonably okay for both.

Of the two main methods of producing API printer dialogs which are available
to you the vbprndlg.DLL is by far the easiest to use, so I would suggest
that is what you should do. After deciding to use the vbprndlg.DLL (if that
is what you in fact decide to do) then you still have the choice of drawing
methods (how you actually print your stuff to the printer). You can either
use the properties returned by the vbprndlg.DLL dialog to set up the VB
Printer Object accordingly or you can alternatively draw your print output
using API drawing methods directly to the hDC returned by the vbprndlg.DLL
dialog.

The former case (setting up the VB Printer Object and its settings from the
stuff returned by the vbprndlg.DLL dialog and using the VB Printer Object to
do your printing) allows your user to successfully select many of the most
important settings, but there are some things on some printers that the user
will be unable to successfully select because the vbprndlg.DLL does not have
properties for all possible individual settings which the user may make in
the dialog, partly because it is in some cases unable to return a specific
setting as a property and partly because some of the settings cannot be
"eaten" by the VB Printer Object anyway and so the vbprndlg.DLL does not
have properties for them.

The latter case (drawing your output using API methods directly to the hDC
returned by the vbprndlg.DLL, instead of using the VB Printer Object) allows
your user to successfully select all of the available printer settings
without exception and so in that respect it is a better method, but it
requires a lot more code and has a greater learning curve.

Considering that you have said that your are a newbie I would suggest that
you use the VB Printer Object methods to draw the page (Print, Line, Circle,
etc, etc) and only move on to using the API (GDI) page drawing methods if
you come across a limitation that is a problem for you, and after you have
mastered the VB Printer Object methods so that you will have a better idea
of the sort of stuff that can be done.

So, to recap, my suggestion is that for the time being you use the
vbprndlg.DLL for showing the dialog and the VB Printer Object for doing the
actual printing, unless you specifically come across anything that you want
to do and that you cannot do using those methods. But if you do decide that
you would rather use the API methods instead of the VB Printer Object (in
which case you can still use the vbprndlg.DLL for the dialog), and if you
are prepared to accept a bit of a learning curve, then post again.

Mike



Sat, 09 Jul 2011 22:47:53 GMT  
 API PrntDlg function
Hi Mike Williams
Thanks for taking the time to explain very clearly the options available, I
am going to follow your suggestion and use the vbprndlg.DLL for showing the
dialog and the VB Printer Object for doing the actual printing. I have
started to build a test project to do just that.
I am going to order a API Programming Book and run some more tests I hope by
then I can try to go over to API.

Ron

Quote:



> > In reply to your helpful post the truthful answer is
> > I do not know, as I have said before I am a self
> > taught newbie. The post was because on a previous
> > post it was said "I do not use Common Dialog I use
> > API's" so thats why I posted this question.

> I do remember making a statement along those lines some time ago but I can't
> remember in what context it was made, although I think I was probably
> referring to the fact that the standard VB CommonDialog Control has a number
> of limitations and that I therefore use an API printer dialog instead, which
> is much more flexible, although I do sometimes also use the API (GDI)
> methods insteads of the VB Printer Object methods to actually draw the
> printed output.

> > All of my printing has been created from information
> > posted by you in examples etc. I want to improve my
> > project should I move on to to all API's? if yes I will
> > have to get a book. Lay it on the line I will not be
> > offended.

> Regarding whether to use the VB methods or the API for printing there are
> two separate things to consider. The first thing to consider is the method
> of showing the printer dialog, which can be done in a number of different
> ways, for example:

> 1. The VB CommonDialog Control
> 2. The Microsoft vbprndlg.DLL (which is a wrapper around the API dialog
> functions)
> 3. The API printer dialog functions themselves.

> Once you have shown the dialog and the user has made his selections in it
> (the printer he wishes to use and various printer settings such as
> orientation, etc) then you can then use the returned results to set up the
> VB Printer object accordingly and print using the Printer Object's native
> drawing methods (which will work properly only for methods 2 and 3 above) or
> you can alternatively hold onto the returned hDC and print directly to that
> hDC using the API drawing methods (which will work properly for all three
> methods above).

> The second thing to consider is the actual printing itself (the drawing of
> stuff onto the page) which can also be done in a number of different ways,
> including (but not limited to):

> 1. Print to the VB Printer Object using native VB drawing methods.
> 2. Print to the VB Printer Object using API (GDI) drawing methods.
> 3. Print to a hDC returned by the CommonDialog Control using GDI drawing
> methods.
> 4. Print to a hDC returned by the vbprndlg.DLL using GDI drawing methods.

> These things (and others) can be 'mixed and matched' in all sorts of
> different ways, and you need to consider the various advantages and the
> various limitations of all of them, which is far too much for me to go into
> here. Personally I would suggest that you use an API dialog (rather than the
> CommonDialog Control) because the CommonDialog Control is not much use if
> you want to set up some initial default printer settings and also not much
> use if you are printing using the VB Printer Object's native drawing methods
> (although it is fine in the latter respect if you are drawing your print
> output using the API drawing methods), whereas the API dialogs are
> reasonably okay for both.

> Of the two main methods of producing API printer dialogs which are available
> to you the vbprndlg.DLL is by far the easiest to use, so I would suggest
> that is what you should do. After deciding to use the vbprndlg.DLL (if that
> is what you in fact decide to do) then you still have the choice of drawing
> methods (how you actually print your stuff to the printer). You can either
> use the properties returned by the vbprndlg.DLL dialog to set up the VB
> Printer Object accordingly or you can alternatively draw your print output
> using API drawing methods directly to the hDC returned by the vbprndlg.DLL
> dialog.

> The former case (setting up the VB Printer Object and its settings from the
> stuff returned by the vbprndlg.DLL dialog and using the VB Printer Object to
> do your printing) allows your user to successfully select many of the most
> important settings, but there are some things on some printers that the user
> will be unable to successfully select because the vbprndlg.DLL does not have
> properties for all possible individual settings which the user may make in
> the dialog, partly because it is in some cases unable to return a specific
> setting as a property and partly because some of the settings cannot be
> "eaten" by the VB Printer Object anyway and so the vbprndlg.DLL does not
> have properties for them.

> The latter case (drawing your output using API methods directly to the hDC
> returned by the vbprndlg.DLL, instead of using the VB Printer Object) allows
> your user to successfully select all of the available printer settings
> without exception and so in that respect it is a better method, but it
> requires a lot more code and has a greater learning curve.

> Considering that you have said that your are a newbie I would suggest that
> you use the VB Printer Object methods to draw the page (Print, Line, Circle,
> etc, etc) and only move on to using the API (GDI) page drawing methods if
> you come across a limitation that is a problem for you, and after you have
> mastered the VB Printer Object methods so that you will have a better idea
> of the sort of stuff that can be done.

> So, to recap, my suggestion is that for the time being you use the
> vbprndlg.DLL for showing the dialog and the VB Printer Object for doing the
> actual printing, unless you specifically come across anything that you want
> to do and that you cannot do using those methods. But if you do decide that
> you would rather use the API methods instead of the VB Printer Object (in
> which case you can still use the vbprndlg.DLL for the dialog), and if you
> are prepared to accept a bit of a learning curve, then post again.

> Mike



Tue, 12 Jul 2011 18:18:08 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Win API functions that don't seem to exist in Win32 API

2. Announcing API-SPY API Function Program

3. API Function Tool (API-SPY)

4. Using API Function

5. Accessing API Functions

6. API functions

7. API CreateProcess Function

8. Calling API Functions

9. API - Lstrcpy function

10. Calling Windows API functions with string parameters from Access

11. Checking Disk Space API/Function?

12. VBA functions vs. API

 

 
Powered by phpBB® Forum Software