Recent improvements in Filemaker have let me take a second look at the way I do many tasks in databases I have designed. This month I will review printing scripts.
Most databases have a set of scripts that handle printing tasks. Using a single set of scripts accomplishes XX tasks at the same time. 1) it is a great exercise in learning how to write more modular code. Write it once and use the same code all over your solution. 2) at the same time it creates a unified way to accomplish the task. No matter where the user is in the database, they know how to print and what will happen when they hit the print button.
In solutions using Filemaker 7 through 9, I typically handle printing with a script that gives the user this experience;
- Click a print button
- Ask if you are printing the current record or the found set
- Ask if you want to print or save as PDF
- Bring up a new window showing the report, in Preview mode, paused.
- The User clicks ‘continue’
- The Print dialogue comes up
- User prints (or cancels)
- New window closes, leaving the user where they started.
Here is a typical Print script:
The problem I always had with this is that it is not always obvious for a novice. Although obvious to the developer, I think I have had to tell every single user I have ever trained, “After you click the Print button, you have to hit the ‘continue’ button, it is on the left” The expected action, clicking the close window widget, doesn’t work, since the script is paused.
This is all different in Filemaker 10. Taking advantage of FM 10 gives us two advantages. 1) scripting can be more flexible and simpler 2) the users can have more flexibility. In a Filemaker 10 solution, here is how I now handle a typical printing routine;
- Click a print button
- Bring up a new window showing the report in preview mode, expose the toolbar
- User clicks the Save as PDF, or Print button in the toolbar
- Closes the window using the window button.
The main differences from the users perspective is that they can chose the PDF, or Print options after seeing the printout. They can close the window using the window tool, or leave the report up for later. Since there is no script running, the user can leave the window open and return to the solution, if they want. I have given the users more choice and saved myself script steps too.
Here is a typical Print Script that I am now using;
If you want to perform any actions after printing, you can perform them using custom menus. Attach a script to the “Print” menu item that perfoms your script when the print command is successfully completed. But in general, being aware of the new features in Filemaker 10 lets you give the users more power in their solutions and at the same time letting you use less scripting.
Speak your Mind. Using Comments, part 1.
Recently I was on a family trip to Pittsburgh. We were walking around the campus of Carnegie Mellon and I saw this memorial brick;
It got me to thinking about some of the monster databases that I have had to take over for clients. When I take over a project, often I am spending a great deal of time just trying to figure out what the developer was trying to do.
Our earlier posts on this blog are generally concerned with improving the user experience(better printing workflow) or getting more out of your data (One Report two sets of summarized data). Today I would like to return to that lowly person, the developer. Anything that I can do that can make my job easier will make be a better developer and ultimately make my customers happier. Or as my grandfather would say to my grandmother, “What would you do if I got hit by a bus?” Continue reading ‘Speak your Mind. Using Comments, part 1.’