When the printer that a report was previously formatted for can't be
found, Access displays a message box asking if I want to use the
default printer. When I OK this the report is displayed on the screen
and I can then print it. Problem is next time I open the report I
have to go through the same procedure.

I've done some tests and this only applies to an mde. If an mdb is
being used Access remembers the new printer selection. Is there a fix
that can be applied to force an mde to remember the printer selection?

On Wed, 5 May 2010 19:20:27 -0700 (PDT), Wayne
<cqdigital (AT) volcanomail (DOT) com> wrote:

I haven't tried this, but probably not. This would require a change to
the design of the report, and that can't be done in a compiled
version.
You could keep the new printer in some table, and use the Printer
object to redirect the printout, but that's not a trivial matter.

-Tom.
Microsoft Access MVP

On May 6, 1:27*pm, Tom van Stiphout <tom7744.no.s... (AT) cox (DOT) net> wrote:
Thanks for the reply Tom. What I find interesting is that I always
distribute the app as an mde and I've never had anyone complain about
this before. I'm fairly certain that if people had been seeing the
problem they would have let me know. I'm wondering if it has
something to do with the fact that the printer that can't be found
(that is present in my design environment) is a pdf printer, Bullzip
pdf to be precise.

I think it's still rather risky to distribute any application with a hard
coded a preexisting printer setup as defined in a report.

The above will cause you nothing but problems.

I would strongly suggest that for all reports you simply set those reports
to use the default printer. That way what ever default printer the user
selects will be where the report will be sent to. It's rather easy and most
users can grasp and understand this concept quite easily.

If you must have report that needs to be sent to a particular printer, then
I suggest you simply add a couple extra lines of code. With access 2003 (and
beyond) there is a printer object. It very trivial matter to set up
something that switches the printer , prints report and then puts things
back exactly as they were.

eg:

So, to save/switch, you can use:

dim strDefaultPrinter as string

get current default printer.
strDefaultPrinter = Application.Printer.DeviceName

switch to printer of your choice:

Set Application.Printer = Application.Printers("HP LaserJet Series II")

do whatever, walk the dog, print some reports...

Now, switch back:

Set Application.Printer = Application.Printers(strDefaultPrinter)

At the end of the day you it really hard to distribute applications to users
in which you have no control over the types of printers they have installed.
In fact even on machines when they install the same printer they'll often
get a slightly different name or slightly different version of the printer.
Again this means your particular defaulted report setting will not work.

In simple plain English:

It makes NO sense to distribute an application to users' computers with a
predefined printer that you don't know they're going to have. If the end
Access user is not designing and building reports and does not have control
over these aspects, then they don't have control over a predefined printer
that you stick into that system either.

Furthermore even when they do install that same printer and driver, they'll
often get a slightly different printer name depending on the version of
windows and thus again the predefined printer in access will not find nor
pick up that printer.

Keep in mind for things like pdf creation, that's one of the reasons why I
use Stephens free example for 2003, as it means you actually don't switch
printers to create a pdf. In fact, you don't even install a pdf driver. so,
it just works, and it works well even with a mde.

What's nice for access 2007 runtime and beyond is native pdf file creation
is built into the system. You thus don't need to install a pdf printer or
even place some .dll's like you do for Stephens solution. And, you code have
to swtich printers in 2007 to create pdfs from within your applications.

So prior to 2007, I strongly suggest stephen's solution as then you don't
hard code nor preset any printers within your application, and as mention
for 2007 and beyond, you don't even need to install a printer drivers or any
additional software to create PDFs. However to keep in mind for office 2007,
I think if your pre SP2, then you do have to download and install the pdf
ad-in. However if you're running a later eddition, or a post sp2 version of
office 2007, then no additional stalls or even download of software is
required to create pdf's out of reports).


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

can now create




pritner, it can often

to do is offer pain and suffering two users

in that matter Allen Browne and his Printer Selection Utility proved very
helpful to me:
http://allenbrowne.com/AppPrintMgt.html

Michiel


"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote


--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---

On May 7, 12:43*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:


Thanks for the reply Albert. I probably didn't describe the situation
very well in my first post. The report in question had never been
changed to use anything but the default printer. As you have rightly
said, that would be a disaster. I think I've caused the confusion when
I said "When the printer that a report was previously formatted for
can't be found...." My terminology here was incorrect. What I was
meaning was that the Bullzip pdf printer was the last printer that the
report had been printed to, not that I had set the report to
specifically print to that printer. The printer for the report had
never been changed from "default".

I've seen this message box appear before when Access can't find the
printer that the report was last printed to, but usually after it is
OKd once it doesn't appear again. I'm not sure why it persists every
time the report is sent to the printer. Maybe there is something
different happening because it is a pdf printer and not a physical
printer.