Printer Problem With A2003 mde
in [Help]
|
Prev: Hyperion Financial Management (HFM) , Jersey city, NJ
Next: Hyperion Installation and Architecture DBA , Chicago, IL
From: Wayne on 5 May 2010 22:20 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 5 May 2010 23:27 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 6 May 2010 02:58 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 6 May 2010 22:43 > > 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 7 May 2010 02:10
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 --- |