6 Replies Latest reply on Feb 27, 2010 10:11 PM by RickWhitelaw

    Multiple printers produce unpredictable results - FM10, XP Pro

    scubed_1

      Summary

      Multiple printers produce unpredictable results - FM10, XP Pro

      Description of the issue

      Problem: Inconsistent printing using multiple printers with scriptsSystem: FM10 Pro and AdvancedOS: XP Pro I have an application that uses three different printers for various reports, labels, barcodes, receipts, etc. One of the three also needs to print in both landscape and portrait, depending on the item being printed. All printing is done without dialog using scripts. The users of the application do not have time to select a printer, paper, format, etc. I've tried scripting this a million ways, with none working. This is how it is right now and it works some of the time: I have a separate script for each printer and two for landscape and portrait on the dual purpose printer. I call the script with a layout of what I want to print in browse mode. Each script does a 'print preview' with no dialog and a setting appropriate for the printer and form. It then goes to preview mode and does a print with no dialog.It works for a while, but sooner or later either landscape or portrait becomes the only way that the scripts will print. In some cases the output goes to the wrong printer. In other cases, the paper size or landscape/portrait change is ignored or carried over to the next print operation on a different printer. One real bug that causes severe problems is when the paper size is too small when entering preview mode (in spite of the print preview being entered correctly - I think) and a modal dialog box comes up with an error message. It has a cancel button which does nothing. The only way that I can get it to go away is to quit Filemaker. It came up once during a script debugging session and I had to bring up the windows task manager to shut filemaker down. I've tried a few plugins. MyFMButler seems to get it all right except for the landscape/portrait problem. I haven't tried their capture-restore function since it is Windows only and I'd love to keep this compatible with Macs since we have both in the shop. I've also tried a few vbscripts and the PRINTUI DLL . I've changed the default printer with scripting. I've saved a specific configuration of paper and portrait/landscape. No matter. It still fails. Again, I'd rather not use a windows specific solution unless I really have to. What I'd really like to know is how it is supposed to work. These may sound like dumb questions, but I can't find examples or documentation that tells me the story: 1. Do you have to go to preview mode to get proper printing using a script? If so, does the 'enter preview mode' script command have any effect on the printer, printer paper, or format - other than bringing up error messages about headers and footers being too big? It seems to know something about the print format and paper size and it does change if I bring up the menu (File/Print Preview)directly -  without scripting. Should the 'Enter Preview mode' statement come after the 'Print Preview' statement? 2. The documentation says that 'Print Preview' and 'Print' script commands retain their 'specified print options'. Does this stickiness occur during the script process or does it happen when the script is executed? Should I duplicate the print options in the matched 'Print Preview' and 'Print' script commands or should I just set them in the 'Print Preview' and have the Print just have the 'no dialog' option? 3. If I just perform a 'Print[No Dialog]" does this use the windows default printer? or does it use the printer that was the default upon entering Filemaker? (I noticed that Filemaker does keep a 'printer' entry in the preferences in the windows register.) or does it use the last printer used? Or something else??? 4. Some wag mentioned that not only should you keep separate scripts for each printer and mode ( did that), but that you need to keep these scripts in separate files! If this is a solution, then I'd do it, but I have a zillion different tables that are linked together and I'd have to reference them all and move a layout or two into the files, as well. This is worth it if it will solve the problem, but if there is a simpler way, please let me know. Please, please, please, can anybody supply some example of multiple format and multiple printer scripts that work in FM10 on both Macs and PCs? If there are more of you with similar problems, please chime in. I don't know if I am coping with a bug or if some decent documentation on how all these things interact would make everything work. I'd love to have it be the latter, so Filemaker moderators - if you have some decent documentation, please let me know.

        • 1. Re: Multiple printers produce unpredictable results - FM10, XP Pro
          bmerc
            

          It's not you. It's FileMaker's buggy printing.

           

          Basically, FileMaker's printing scripts cannot be relied on to work correctly with any sort of specialty printer or unusual stock size. Scripting for a simple single-printer environment usually seems to work, but try printing to a label printer, bar code printer, card printer, or anything else, and you're going to have problems.

           

          One of the latest problems I've encountered is that scripts for printing to a Dymo LabelWriter (the single most popular label printer in the world) spontaneously change to a different label size. I create a script to print to a standard 30323 address label. Save the script and re-open it, and the address label has changed to 11351 Jewelry Label. Or "Custom." Or one of a few other apparently random options.


          Some of the issues I've encountered:
          • Printer settings saved in script steps may be ignored
          • Print Setup script steps and Print script steps interact with each other inconsistently
          • Jobs print to wrong device
          • Scripted printer settings change depending on the NAME of the printer
          • The exact same printer setup scripts may act differently in two different files
          • Scripted printer changes sometimes work, sometimes don't
          • Scripts that print correctly in one version of FM will print incorrectly on a different one.
          • Printing with some Toshiba drivers causes application crash
          • Canceling print jobs may cause a hard crash, possibly corrupting databases
          • Portrait/Landscape orientation incorrectly handled
          • Special page sizes are simply flat-out wrong. (This happens even without scripting.)
          • Various other goofy and frustrating printing problems

           

          While there's no real fix, you can do a few things that may minimize the impact of these bugs.

          • Write each printing script assuming it will only work with the FM version you created it on.
          • Never edit a printing script created on one version of FM with a different version.
          • Use local printers whenever possible.
          • Try to avoid using the "No Dialog" option on Print script steps. Showing the dialog, even if the user doesn't make any changes, sometimes prevents some glitches.
          • Make sure all printers and drivers are installed on the computer you edit scripts on, and that they have the exact same names as will be used in production. 
          • When printing labels, cards, and other odd-sized documents, print them to PDF files using a 3rd party print-to-PDF solution (I highly recommend PDFCreator, it's by far the most stable and reliable option I've tried, and I've tried a lot), then use Adobe Reader to print the file to the actual device.  Don't use FileMaker's built-in PDF functionality.

          • 2. Re: Multiple printers produce unpredictable results - FM10, XP Pro
            scubed_1
               Thanks for the reply and for your hints. Unfortunately, I have to use the 'no dialog' option. I'll try the PDF option and see if that works.
            • 3. Re: Multiple printers produce unpredictable results - FM10, XP Pro
              TSGal

              scubed:

               

              Thank you for your posts.

               

              FileMaker Pro 10 is more restrictive than previous versions of FileMaker Pro.  I have specific script steps to print to specific printers.  On my Mac, I have the script steps:

               

              Print Setup [ Restore ; No dialog ]   (my printer name and page size is set when I specify the Page Setup)

              Print [ Restore ; No dialog ]   (again, my printer name is selected, along with Records being browsed)

               

              I have this set for each printer (including a Dymo LabelWriter).  If I want to print to landscape, then I use a different Print Setup and Print steps.  In other words, I specify the printer, page size, records printed.  I never use the Print command by itself, because it may use the Default printer or the last printer that received information.  I don't leave it up to chance.

               

              Some users have selected a printer in Page Setup, but the Print script has a different printer selected and thereby overrides the printer in the Page Setup.

               

              TSGal

              FileMaker, Inc. 

              • 4. Re: Multiple printers produce unpredictable results - FM10, XP Pro
                jrossi85
                  

                I wanted to be able to print to multiple printers on our network without having a dialog pop up.  To do this, I printed to a PDF in the temporary files path and then sent an open document event to the print command.  I am only running on Windows, but there may be something similar in Mac that will allow you to script an alternative if the user is on a Mac.  In my case, this didn't matter.  A couple of notes on the print command:

                 

                - As I said, this *specific* command is for Windows only, if you find another print command for Mac, then that will be the only line to change

                - The /D: parameter the printer name.  All of our printers are hosted on a single print server (hence the ServerName).  For a local printer, use the local PORT name (COM1, LPT2, etc.).  When using a server-hosted printer, use the printer NAME.

                - Be sure to escape the backslashes

                - The below $command variable would be set to:

                 

                print /D:\\ServerName\PrinterName "C:\Documents and Settings\username\Local Settings\Temp\filename.pdf"

                 

                Print Setup [Restore; No dialog]

                Set Variable [$filepath; Value:If(Get(SystemPlatform) = -2;"filewin:";"filemac:") & Get (TemporaryPath) & "filename.pdf"

                Save Records as PDF [Restore; No Dialog; $filepath; Current Record]

                Set Variable [$command; Value:"print /D:\\\\ServerName\\" & $printerName & " \"" & Replace($filepath;1;9;"") & "\""

                Send Event ["aevt";odoc;$command]

                 

                The print setup keeps my landscape, etc. formats to print to PDF.  This is working perfectly for me.  This allows me to print without having a dialog pop up so I can use it in kiosk mode.  It also allows me to easily add new printers.  Heck, the server name and printer name can even be scripted if you want to. 

                • 5. Re: Multiple printers produce unpredictable results - FM10, XP Pro
                  mdscarpa

                  jrossi85, can you elaborate a little? My understanding is if I wanted to print to a USB printer i would add a script step: "print USB001"C:\Documents and Settings\username\Local Settings\Temp\filename.pdf"   I am not sure how to add custom script steps though. I am using FM10 on windows. I need to print to a DYMO and letter size to laser printer... it has been a nighmare.

                  • 6. Re: Multiple printers produce unpredictable results - FM10, XP Pro
                    RickWhitelaw

                    Scubed wrote:

                    "1. Do you have to go to preview mode to get proper printing using a script? If so, does the 'enter preview mode' script command have any effect on the printer, printer paper, or format - other than bringing up error messages about headers and footers being too big? It seems to know something about the print format and paper size and it does change if I bring up the menu (File/Print Preview)directly -  without scripting. Should the 'Enter Preview mode' statement come after the 'Print Preview' statement?

                     

                    2. The documentation says that 'Print Preview' and 'Print' script commands retain their 'specified print options'. Does this stickiness occur during the script process or does it happen when the script is executed? Should I duplicate the print options in the matched 'Print Preview' and 'Print' script commands or should I just set them in the 'Print Preview' and have the Print just have the 'no dialog' option?

                     

                    3. If I just perform a 'Print[No Dialog]" does this use the windows default printer? or does it use the printer that was the default upon entering Filemaker? (I noticed that Filemaker does keep a 'printer' entry in the preferences in the windows register.) or does it use the last printer used? Or something else???

                     

                    4. Some wag mentioned that not only should you keep separate scripts for each printer and mode ( did that), but that you need to keep these scripts in separate files! If this is a solution, then I'd do it, but I have a zillion different tables that are linked together and I'd have to reference them all and move a layout or two into the files, as well. This is worth it if it will solve the problem, but if there is a simpler way, please let me know."

                     

                    I'm a Mac user, and although I've my share of issues regarding printing to multiple printers, what I hear from some Windows users on this forum is nothing short of horrible. In my experience, and I know some things differ on Windows,

                     

                    1. There's no reason to enter Preview mode to execute a print job.

                     

                    2. I assume "Print Preview" means the "Print Setup" script step. This step selects orientation etc. and the printer the job should be formatted to. On a Mac, there's a Format for Any Printer option. I use this. Doesn't exist on Windows. The "Print" step selects the printer for the job. This is needlessly confusing. However, I do a lot of scripted printing, and always without dialog. The scripts always execute properly. Correct paper size, orientation and printer.

                     

                    3. If you don't specify a printer FM will use the default printer as is documented. On a Mac (not sure about Windows), on the OS level, you can set the default printer to "last printer used".

                     

                    4. I don't understand #4. Scripts need to be in the file from which they execute, but scripts can call scripts in different files, pass parameters etc.

                     

                    The real problem lies in having to specify printer names. If you hard code printer selection into scripts, what happens when the solution is used on a different machine (with different printers)? My solution is to use shell scripting for all print jobs. That way the user can name their printers in a Preferences table and the printer name can be expressed as a variable. Then print scripting becomes more about specifying  a TASK rather than a printer. If the user decides a certain task would be better performed on a different printer, simply open preferences and reassign another printer to a type of task. No changes to any scripts. Virtually all relevant print options (number of sides, short or long edge, # copies, orientation etc. ) can be converted to variables and passed to cups with lpr commands. I've converted most of my scripts to this method and I have a dozen or two to change still, but I'm pleased with the results.

                     

                    RW