From: Wayne on
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?
From: Tom van Stiphout on
On Wed, 5 May 2010 19:20:27 -0700 (PDT), Wayne
<cqdigital(a)volcanomail.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


>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?
From: Wayne on
On May 6, 1:27 pm, Tom van Stiphout <tom7744.no.s...(a)cox.net> 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

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.
From: Albert D. Kallal on

>
> 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(a)msn.com

can now create




pritner, it can often

to do is offer pain and suffering two users

From: Michiel Rapati-Kekkonen on
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(a)msn.com> wrote in message
news:M7LEn.88$0B5.42(a)newsfe05.iad...
>
>>
>> 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(a)msn.com
>
> can now create
>
>
>
>
> pritner, it can often
>
> to do is offer pain and suffering two users


--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---