Solved

Code to change DYMO printer

Posted on 2014-09-07
12
155 Views
Last Modified: 2014-09-08
I see "Beehilly" was struggling with this, but it did not look like it got resolved.

For my Accde on the server... User swapping a DYMO printer might change the Printer Name (Eg.  "Dymo 400" to "Dymo 400 Turbo"  and when this happens my Accde on the server can not resolve how to change this for 3 reports I have.

I've tried combinations of this....  w/o luck.    Any ideas?

  DoCmd.OpenReport ReportName, View:=acDesign, WindowMode:=acHidden
  Dim prt As Object
  Set prt = Application.Printer
  Application.Printer = Printers(UseThisPrinterName)      ' (e.g. "DYMO Labelwriter 400 turbo")
  Set Reports(ReportName).Printer = Application.Printer  

I think something like this worked on Server 2003,  but now moved things to Server 2008 and no luck.

I sure appreciate any help.
Frank
0
Comment
Question by:FrankBabz
  • 6
  • 6
12 Comments
 
LVL 84
Comment Utility
Your question is not in the right areas. You should always put Access questions in the Access zone specifically, and then in the Microsoft Office zone if appropriate.

The code you're using will work, but you must have the printer name EXACTLY right. If your user changes the printer name, your code would need to reflect that. You could cycle through all the Printers on the machine, using the Printers collection, and make sure the correct printer is installed when the application starts. If your code cannot find that printer, you could have the user select the correct printer, and then store that value in a table.
0
 

Author Comment

by:FrankBabz
Comment Utility
Hi Scott…   2 great tips today!

I have a table already that contains the name (e.g.” Dymo 400”) as the “driver” for which my 3 accde reports were created.  Having that info at hand… it should eliminate need to prompt user.

Only Dymo report names can start with “Dymo “ and that made it easy for me to collect them.
I can iterate the 3 reports to see if each one has the correct name/driver.

If yes… that’s great…. move on to next.

If no … can this be fixed?  (it is here where I am flailing and need help)

Unless the driver was uninstalled, it is there on the server, and I would like to replaces the wrong driver with the driver that belongs with the report (as my table dictates).

I mainly wonder in this case if just updating the table entry to new driver name would work most of the time (maybe)?  For example I doubt there are any layout differences between drivers for “Dymo 400” and “Dymo 400 Turbo.”

If all code fails, advise user that someone swapped Dymo device and original device needs reinstalled.  And/Or Accdb needs to rebuild 3 reports with new driver…  and new Accde…  and updated Table entry.  

Thanks in advance for your help….
Frank
0
 
LVL 84
Comment Utility
I have a table already that contains the name (e.g.” Dymo 400”) as the “driver” for which my 3 accde reports were created.  Having that info at hand… it should eliminate need to prompt user.
So long as that name does not change, then you're good - just use code to pull that Printer name, and use code to set the name for that report. If the name does change, then your code would have to reflect that. Even if the name changes from "Dymo 4000" to "Dymo 400 T", you'd have to change that.

You could cycle through printer names and look for the one beginning with Dymo, if that makes sense. I don't think you'd need to rebuild, however. You don't have to open the report in Design view to set the Printer from code, so generally that means you don't have to recreate the accde file.
0
 

Author Comment

by:FrankBabz
Comment Utility
Thanks Scott...

Dealing with printers and drivers is tough for me.  To find shared Dymo printer installed on the Server....   Is that just a matter of searching the Printer collection?  If so, I can do that.   Yes... any Dymo printer would contain "DYMO " in the name.

My approach was to try and fix each Dymo report to insure proper driver during accde startup.  That would (I think) require opening each report in design view and saving the revised report.  Otherwise, how would I  "just use code to pull that Printer name, and use code to set the name for that report"   unless.....

Perhaps you are suggesting (instead of fixing during startup) to wait until the report is actually being run and then fix (if necessary) proper driver in the report Open event?   Any code snippets you may have would be most appreciated.
0
 
LVL 84
Comment Utility
You cannot open the report in design view in an .accde file, if that's what you're asking, and trying to roll out fixes for specifics like that - i.e. UserA has a printer named "DYMO", but UserB has a Printer named "DYMO1" - would be quite frustrating, and prone to issues.

You can set the default printer just before you open the report:

Dim prt As Printer
Dim prtDefault As Printer

prtDefault = Application.Printer

For each prt in Application.Printers
  If prt.Name = "Your Printer Name" Then
    Application.Printer = Application.Printers(prt.Name)
    Exit For
  End If
Next

'/ now open your report:
DoCmd.OpenReport blah blah
'/ reset the printer:
application.printer = prtDefault
0
 

Author Comment

by:FrankBabz
Comment Utility
Thanks again Scott...

I was on the path to use design view in the accde...   Thanks very much for saving me lots of time and future disappointment.

I presume I would only invoke your code if my Report Name included "Dymo " (per my convention restriction for all Dymo reports).   Now... I wonder if the report was originally designed to use "Dymo A" and Application.Printer sets "Dymo B" which printer will the Report be obliged to try to use?
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 84
Comment Utility
I generally add a table that stores this sort of information - the ReportName, PrinterName, etc - then check that before I print each report. You could create a generic PrintReport function that accepted the ReportName (and other settings, like perhaps NumberofCopies, Orientation, etc) and then use that function to handle the printer change.

Also, be aware that you'd need to set your Report to use the default printer, store the current default printer, change the Application.Printer to the needed printer, and then change the Application.Printer back to that stored default printer. All this could be done in your PrintReport function.
0
 

Author Comment

by:FrankBabz
Comment Utility
I was thinking this might be what needed done (and hoping it would not be the answer)....

                         be aware that you'd need to set your Report to use the default printer

I will give that a try...  but I'm very apprehensive because  DYMO is tightly involved in the design and layout process... and it's not user friendly or nicely documented....  and I've never done a generic printer label before...  Especially worrisome is that my layout will be summoned to eventually work with the real driver.  

Any alternative thoughts?
0
 
LVL 84
Comment Utility
I've worked with DYMO before, but never from Access. I've always done it through .NET, and it was fairly straight forward.

That said, setting your report to use the Default Printer is the norm in Access. You should only set a report to use a specific printer if you're certain that exact printer will be available, and you don't mind changing it when the printer is swapped out for a new one. Otherwise, you should always set Access reports to use the Default Printer (and that's the "default" in Access, to overuse the word):

Default Printer setting
0
 

Author Comment

by:FrankBabz
Comment Utility
This may not be the big a deal as I thought.  For my first label test all I did was change it to Default Printer.

FYI I had to modify your code a bit...

Set prtDefault = Application.Printer    (I needed to add SET)

prt.name is no longer supported...  you must instead choose prt.DeviceName or prt.DriverName

I used Device Name to find the Dymo device wanted.

more later....
0
 
LVL 84

Accepted Solution

by:
Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 500 total points
Comment Utility
Sorry, I was using "air code" so you may find other issues like that as well ...
0
 

Author Closing Comment

by:FrankBabz
Comment Utility
Absolutely fantastic!!!
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

I. Introduction There's an interesting discussion going on now in an Experts Exchange Group — Attachments with no extension (http://www.experts-exchange.com/discussions/210281/Attachments-with-no-extension.html). This reminded me of questions tha…
This article descibes how to create a connection between Excel and SAP and how to move data from Excel to SAP or the other way around.
Learn how to make your own table of contents in Microsoft Word using paragraph styles and the automatic table of contents tool. We'll be using the paragraph styles in Word’s Home toolbar to help you create a table of contents. Type out your initial …
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now