It doesn't work very well in a production environment where the report(s) are run MANY times per day. Like with Sales Orders or Packing Lists warehouse pick lists or Invoices, especially when the printers are networked and/or remote.
To have to select and set up the printer every time you printed a report, (margins, printer, input tray, output tray, orientation, duplex, copies) would be... Well I just don't want to be in phone range for that one. RAG > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Keith DeLong > Sent: Wednesday, May 10, 2006 4:46 PM > To: REALbasic NUG > Subject: Re: Printing Crashes In Windows Explained - WORKAROUND! > > > > After another good bit of testing, I have a proposed > explanation of the > > printing crashing, a new revelation, and a question or two: > > > > 1. Populating a printersetup using ps.setupstring = > SetupString randomly fails > > silently (and fails much more often on HP and network printers) > > I've just stumbled on what think is a simple, 100% reliable > workaround. > Here's the rule: > > ps.setupstring = anything is evil. Don't EVER use this assignment!! > (at least until REAL fixes it). > <SNIP> > I just ran this for over 100,000 print jobs on my most > troublesome HP 1320 > printer driver with zero crashes. > > If you have multiple reports requiring differing formats, use ps() as > printersetup as an array, creating a new setup for each type of report > printed. > > I think the minor inconvenience of confirming the printer, > orientation and > margins -- if needed -- once per program run is more than an > acceptable > workaround until REAL can fix assigning to .setupstring. > > Does anyone see a problem or fatal flaw with this workaround > in their apps? > > Keith DeLong > > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
