Access 2007 How to Programmatically Retrieve Printer Capabilities

[Jack45]

I need to be able to specify a different printer for each report and to have
the individual report pick up sheets from a specific tray in an HP LaserJet
4200 or to pick up the default. With the run-time facility's limitations,
this is very difficult, even for an experienced programmer.

This online help entry (which for some reason I cannot evoke again) refers
the user to the PrinterDemo.mdb file. I couldn't find it and I believe that
there should be a hyperlink to the correct place.

That said, I found PrinterDemo.MDB for Access 10 (2000) and loaded it under
A2003. It works, sort of. I had the impression that it would allow me to
associate a diffferent printer and options with each report. It appears to
reset the options for all reports at the same time and not or even to specify
the same printer with different bins depending on the report. Not a terribly
useful feature, it seems.

I converted the .mdb to A2007's .accdb format and it seems to work similarly
to the A2000 version. So, I can use it as a model.

Just the same, setting a printer on a report-by-report basis and choosing a
particular tray seems far more convoluted than it should be.

Helpful advice appreciated!

 

[Tony Toews [MVP]]

Just the same, setting a printer on a report-by-report basis and choosing a
particular tray seems far more convoluted than it should be.

Helpful advice appreciated!

And unhelpful advice? <smile>

It would appear that the PrinterDemo.MDB uses the using the newish
Printers collection and Printer objects in Access.

The method with the most power, and by far the most complexity, is
using the PrtDevMode data structure.

ACC: How to Change a Report's Printer Using Code Q129397
For more information about PrtDevMode and PrtDevNames, search for
"PrtDevMode property" or "PrtDevNames property," using the Microsoft
Access 97 Help Index or Reports: Change printers from code
http://www.mvps.org/access/reports/rpt0009.htm

For more info on some restrictions, such as not being able to open a
report in design mode in MDEs, do a search on prtdevmode at the
Knowledge Base at support.microsoft.com. (You might be able to get
around this particular problem by using Automation to open a report in
an MDB and somehow passing appropriate data to the MDB.

This code can also be found in the Developers Handbook.
www.developershandbook.com. I'd recommend spending the money on those
books even though the last version is A2000. The code in their will
save you enough.time and effort to make spending the money very
worthwhile.

Also note that this is very complex code and is recommended only for
advanced programmers.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Jack45]

And unhelpful advice? <smile>

It would appear that the PrinterDemo.MDB uses the using the newish
Printers collection and Printer objects in Access.

The method with the most power, and by far the most complexity, is
using the PrtDevMode data structure.

ACC: How to Change a Report's Printer Using Code Q129397
For more information about PrtDevMode and PrtDevNames, search for
"PrtDevMode property" or "PrtDevNames property," using the Microsoft
Access 97 Help Index or Reports: Change printers from code
http://www.mvps.org/access/reports/rpt0009.htm

For more info on some restrictions, such as not being able to open a
report in design mode in MDEs, do a search on prtdevmode at the
Knowledge Base at support.microsoft.com. (You might be able to get
around this particular problem by using Automation to open a report in
an MDB and somehow passing appropriate data to the MDB.

This code can also be found in the Developers Handbook.
www.developershandbook.com. I'd recommend spending the money on those
books even though the last version is A2000. The code in their will
save you enough.time and effort to make spending the money very
worthwhile.

Also note that this is very complex code and is recommended only for
advanced programmers.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Jack45]

I'm beginning to think that a rational approach to managing approximately 100
reports with diverse printer destinations may be to create a small table
that's managed by a form that allows a user to assign non-default printers
with certain attributes, such as preferred tray for those printers to an
individual or even a group of reports. I envision something like a continuous
form with the report names and a combo box or two to hold the available
printers (including default) and another field for their associated tray
numbers. For example, the report name would have a place for HP LJ 4200 and
another field for tray #2. This way, the user could set this up once, the
table could reside in the back-end of the database and be updateable whenever
a user wanted to include a new printer in his "profile."

By including the report/printer assignments in a table in the back end, I
could update the front-end and not worry about the user's losing the
assignments s/he carefully laid out.

Thoughts?

 

[Tony Toews [MVP]]

I'm beginning to think that a rational approach to managing approximately 100
reports with diverse printer destinations may be to create a small table
that's managed by a form that allows a user to assign non-default printers
with certain attributes, such as preferred tray for those printers to an
individual or even a group of reports. I envision something like a continuous
form with the report names and a combo box or two to hold the available
printers (including default) and another field for their associated tray
numbers. For example, the report name would have a place for HP LJ 4200 and
another field for tray #2. This way, the user could set this up once, the
table could reside in the back-end of the database and be updateable whenever
a user wanted to include a new printer in his "profile."

By including the report/printer assignments in a table in the back end, I
could update the front-end and not worry about the user's losing the
assignments s/he carefully laid out.

Thoughts?

Makes a lot of sense to me.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/