4 Replies Latest reply on Jul 9, 2014 8:29 AM by FilmUser

    Script can't remember Print Setup selections



      Script can't remember Print Setup selections


           FMP 12 v1 Windows 7 (working on the IT group to get us the v4 updater)

           This reminds me of an issue with an earlier version of FMP, you set the printer and parameters in a script for print setup and every time the script is run, the script ignores its setup and mimics the print setup choices of the last print.

           Situation is several network printers, shared by 20-odd file clients (FM Server 12 hosting). 3 of these users print to a special Zebra printer (also on the network) on small labels. The setup parameters are much more involved than a normal page size and orientation. Access to script writing is not given to the folks who print, they print by hitting buttons, to control just this kind of thing.

           If the Zebra printer is set as the default at the system level, then it overrides the selections in other scripts (some scripts are looped through records to collate prints, printing to a normal letter size copy machine), trying to print to the Zebra printer all the time. I have had to uncheck all of the script choices, "perform without dialogue" so that each time the user can choose the right printer, which is quite annoying in a script with many records cycling through 3 layouts.

           I just made one of the users' OS printer default one of the other network printers, and when we ran the script to print on the Zebra, it came up another printer (not her default) and when manually choosing the Zebra printer in the setup dialogue, all of the parameter choices had to be made all over again. We then repeated this and half of the parameters had to be reset.

           What goes here? Am I missing something?

        • 1. Re: Script can't remember Print Setup selections

               For better control of the printing process, you might consider using the MyFMButler plugin.

               To work around such issues, I sometimes set up a "print" script that does not print anything. It pulls up the correct found set, enters Preview mode and pauses. In preview mode, wrong paper sizes or print orientations are usually quite visible.

               To print, the user then selects print from the File menu like they would any other application and can then select the print and printer set up options that they need in order to print successfully.

               The down side to this option is that you may need to teach your users the difference between "records being browsed" and "Current Record".

          • 2. Re: Script can't remember Print Setup selections

                 Well. . . I don't remember needing a plugin or work around for this is the last couple of Filemaker versions. In fact, I remember a local developer (a member of the Richmond XMug chapter) expressing relief when this was "finally" solved in either FMP 10 or 11. I was using multiple printers then, and never had the problem after upgrading.

                 While your interim scrip will alert users to the issue, it's still an interruption, and these are not highly skilled FM users. The other thing is that the setting for the label printer include specific "page, or label" size, intensity, margins, etc, all set in the driver interface.

                 My issue with the plugin solution is that I'm working on a very large corporate network, and everything is tightly controlled and vetted by the IT group before allowing installation on any computer (we are still trying to update to FMP 12 v4). This problem has significantly cut into the efficiency factor of FMP in our work flow.

                 Are these really the only solutions? And why can't the script remember what it is set for, anyway? What is the point of including Print Setup in the script if it can't remember it?

                 Not meaning to rant here, I'm just pushing a bit before giving in to a plugin to fix something that seems surmountable natively.

                 Say it ain't so! (is it possible that v4 will fix this?)

            • 3. Re: Script can't remember Print Setup selections

                   FileMaker has always been a bit hit or miss when it comes to printer interaction. I've always thought that this was due, in part, to the fact that the code needed to generate a print job file in FileMaker is quite a bit more complex than that from most other applications. Whether that is true or not, it has always been a potential issue for specific printers (or more precisely, certain printer drivers) that fail to "play nice" with specific version/OS combinations of FileMaker. I've tended to use this Preview/Pause method as an effective method that has avoided a lot of issues in getting solutions to work with particular printers.


                        While your interim scrip will alert users to the issue, it's still an interruption, and these are not highly skilled FM users.

                   Yes, but this often does not require a high degree of skill on the part of the users. The system requires them to use what for most computer users is a very familiar method for printing from just about any computer software. And it is often possible to resolve the "records being browsed vs. current record" issue by telling the users to always select "Records being browsed" and then designing the preview script to isolate the current record in a found set of a single record whenever the report is intended to only print the data from the layout's current record.

                   Another thing that you can try is to run an Advanced Options Recover on a copy of your file and test the recovered copy to see if you get any change. Select these Advanced Recover options:

                   Copy File Blocks As-Is.
                   Delete cached settings

                   These will reset a few things that can affect printer operation back to "factor spec" and that, once in a great while, can fix a printer issue.

              • 4. Re: Script can't remember Print Setup selections

                     Thanks, Phil, for your last post.

                     I did some web research this morning on this issue, some of it leading back to other posts on this forum, and I'm convinced that short of a plug in, work arounds are it.

                     My previous experience was with a Mac, so this may have been the reason the scripts ignored any previous printer. One last thing I'll try is to set the default printer (OS level) to one I never use, just to see what happens.