FMButler 2.2 - Far too expensive an option. Can't believe FM doesn't allow us to control basic operation such as the printer - but do believe its just not well documented.
Can you not specify the printer for the task from inside FM? This will not change the default printer for any user when they print otherwise.
I don't know. Can you - hence my question.
The simple answer is yes, you can. On a Mac there's a setting that sets the default printer as the last one used. Good thing to uncheck. On a Windows machine? I don't know.
As stated, this is a Windows environment.
Hugo, yes, I understand you're in a Windows environment. I used the Mac example thinking there may be a Windows equivalent.
This has been discussed in other threads, which I've followed, because I, too am currently working in a Windows (7) environment and having problems with this.
When on the Mac, several years ago in FMP 10, the script always worked - first step Page Setup, second step Print, which always worked - running each script set the page setup and print selections as scripted, no matter the sequence of script executions.
Now on Windows, FMP12, scripts do not execute as scripted - but rather as the last print configuration used. One of our printers is a special bar code printer printing to a small label printer, with unusual page (print) setup and print settings. It became so much trouble, that we use one computer to print all of these special labels (and no other printing), and even then, the user has to re-orient the set up and print settings for the first print done after logging into the computer, then the script will remember it's own settings.
The company I'm contracted to will not purchase Butler.
I haven't seen a lot of reports about this problem with FMP 12 - windows, but it was definitely an issue in many older versions.
You might try recovering the file with the following advanced recover options specified:
Copy File Blocks As Is
Delete Cached Settings
There's no guarantee that this will fix the problem, but might and costs you nothing to try.
One workaround that I have used on windows systems with older, legacy systems is this:
Script does all that is needed to find and sort records for the output. If this is printing data from a single record, it isolates that record in a found set of just that record.
Script enters preview and pauses
Continuing the script returns the user to their original layout without anything printed.
To print, the user selects print from the File menu while the script is paused. For almost all users, this is a familiar and non-intimidating thing to do as any other app in windows generally prints by selecting Print in the File Menu anyway.
By seeing the previewed copy, the user is often presented with very obviously wrong potential output if the wrong printer is selected so this feedback is often all that is needed to prompt them to select a different printer, page orientation, paper size, etc.
The main "catch" is that you have to educate/remind users about the difference between records being browsed and current record options if your report prints from a found set of multiple records. (Which is why I isolate single records when such is possible as then both print options produce identical results.)