Script triggers Archives

12 Days of FileMaker 12: Script Trigger Enhancements

May 14, 2012 by Susan Fennema Leave a Comment

Using Script triggers has become common place in FileMaker development — and with the new enhancements in FileMaker 12, we have even more power.

Script Trigger Enhancements in FileMaker Pro

In this session from the 12 Days of FileMaker 12, we look at an update to Script Debugger in FileMaker Pro Advanced for globally enabling/disabling triggers, as well as new indicators, and new triggers.

About Sameer Khan

Sameer Khan is the presenter. He is a FileMaker 9-11 Certified Developer and Authorized Trainer employed by Anvil Dataworks, a development firm outside of Washington DC. He has been working with FileMaker for over eight years. His students say that he is an interesting person and a knowledgeable teacher.

3 FileMaker Demo Files

October 5, 2011 by Martha Zink Leave a Comment

I presented these demo files during a series of user group meetings in the Bay Area. My goal for each demo file was to incorporate the technique into an existing solution and think of it outside of the box.

Snapshot Link

In this sample file, there are two applications of Snapshot Link:

Launch file
Bookmark when closing

For the launch file, open up the solution. Once you’re at the opening screen with the “About” and “Demo” buttons, create a Snapshot Link and place it on your desktop. As long as the file doesn’t move, the Snapshot Link on the desktop can serve as your launch file.

For the bookmark, there is a script called “On Close” that runs when the file closes (via File > File Options). It shows a dialog and asks the user if his place should be saved. If the user agrees, the script puts a Snapshot Link to the desktop, that the user can click to start off where the database was last left.

Demo File: Snapshot-Link

Filtered Portal

In these sample files, there are two treatments of Filtered Portal:

New approach to tab control
Report management

It’s common to create a solution with tab controls, but what if you wanted to change the look? The layout “Sample Menu | Tab no Hierarchy” shows you how a filtered portal can enhance the user experience and control the tabs. This technique takes a combination of the following:

Hidden Tab Control (Fixed Width of tab = 0) where each tab has an object name
The table “Tab” that stores the tab display name, the menu group, the sort order, and the object name for each menu.
The script “SwitchTabs” takes the user to the correct object based on the object name stored in the Tab table.

The layout “Sample Menu | Tab” takes the technique to the next level, allowing a hierarchy of parent and child. The added tools for this technique work include:

A field in the table “Tab” called “Belongs To” that ties each record to its parent record
A global variable that contains the “Belongs To” value for the filtered portal

The other sample file for filtered portals shows how to use a filtered portal with global fields. Not only is the user interface clean, but the user has control over which reports he can see. You’ll notice the “Not isEmpty( )” in the Filtered Portal calculation. One of the things I’ve learned over time is that if the user selects nothing in a filter, he or she wants to see everything. It is counterintuitive but the expected behavior. Filtered Portals require quite a bit of trial and error.

Demo File: Filtered-Portal

Script Triggers

The latest version of FileMaker Pro introduces a few new triggers. In these sample files, there are several purposes for Script Triggers:

OnViewChange – Changing views (meaing layouts) with the Toolbar
OnObjectValidate – Providing feedback for erroneous data
OnObjectKeystroke – Limiting keystrokes and characters

In the first sample file, the script “Change in Views” is being triggered by OnView Change. If the user clicks on the “list view” from the toolbar, the script is executed, taking the user to a layout with the same data in a list view. The same applies in table and form view. The important part of the technique is consistency in the layout naming. Each one ends with the word that defines the layout view.

In the second sample file, there are three examples:

OnObjectValidate – Allowing a range based on the script parameter (Example: 1 to 10)
OnObjectKeystroke – Not allowing the user to type anything but positive numbers (including the decimal point)
OnObjectKeystroke – Not allowing the user to type anything but numbers (including the dash for negative numbers)

There is also an example involving the drop-down. One of the things my user discovered was the ability to type into the field if the drop-down wasn’t showing. By using OnObjectKeystroke, the user is limited to what keystrokes will occur.

However, it is important to note that individual keystrokes are allowed, even though they don’t produce a character. These keys include backspace, return, escape, and arrow keys. Removing these from the user’s capabilities would leave the user feeling handicapped instead of improving the interface.

Demo File: Script-Trigger

Validation With Script Triggers

August 26, 2011 by Martha Zink 2 Comments

With the post-DevCon madness coming to a slow end, I’m excited to announce that I’ll be traveling the last week in September and participating in the West Coast FMPug Tour! What’s the schedule you ask? Here it is:

September 26 – Seattle
September 27 – Portland
September 28 – San Francisco
September 29 – FileMaker Inc. (the Wedge in Santa Clara)

With that said, I’d like to share with you one of the techniques that I’ll be presenting at the FMPugs – and that’s controlling the user via script triggers. Now I say this cautiously, as I can feel Steven Blackwell rolling his eyes at me from 1500 miles away, concerning himself with Security (and rightfully so!). I do not think that script triggers should be the only means for controlling users and the data they enter, but I do believe that script triggers can give the user a more pleasant experience than JUST validation. I implemented this technique for one of our development customers and they are very happy that their solution is intuitive and the data being entered is accurate. So onward! One of my critiques of validation error messages is their… simplicity. You get a dialog box and a couple of buttons – that’s it. With this example, we can use script triggers to give the user more information and allow them to enter data accurately.

Example 1: Better Dialog Messages

A great use of script triggers is OnObjectValidate, which runs right before validation occurs, which also means the user hasn’t left the field. Imagine having a field where the user has to enter a number between 0 and 100 and the user enters 150. With validation turned on, an error message will show up, but we can add a little more finesse with a script trigger. Here’s what the script looks like:

You’ll notice the use of Get ( ActiveFieldName ) and Get ( ActiveFieldContents ) – the goal here is to abstract the script so that it can be reused in multiple places. In other words, by not tying the script to a specific field, this script can be applied to multiple fields that require the same type of validation. So in plain English, what is the script doing?

Checking to see if the value in the active field is between 0 and 100
If the value is not between 0 and 100, a dialog box shows up with a global field in it. The user can then enter a value in the dialog.
If the user enters a number between 0 and 100, the active field gets set to the value in the global field and the script ends.
If the user enters a number outside of 0 and 100, the custom dialog keeps showing up.

Here’s what the dialog box looks like:

Example 2: Locking the Keyboard

My customer said to me, “I don’t want the user to even be ALLOWED to enter the wrong values with the keyboard.” This is a different approach to a similar problem. Instead of telling the user that he or she did something wrong after the fact, limit what the user can do during data entry.

In this same example, here’s a script that doesn’t allow the user to enter anything but numbers and periods (for decimal places). Now this was initially tricky in that I first wrote this to ONLY allow numbers and periods, but then realized that those aren’t the only keys a user might need while in a field. The other keystrokes that I had to allow were the tab key, and enter key, and the arrows (for navigating within the field).

Note: The script was put into a text editor for ease of reading.

The Let function is the most complex part of this script so let me break out that calculation:

 Let (
	c = Code( Get( TriggerKeystroke ) ) ;
	
	Length ( Filter (  Get ( TriggerKeystroke )  ; "0123456789." & If ( Get ( ScriptParameter ) = "dash" ; "-" ; "" ) ) ) > 0 or c = 9 or c = 10 or c = 28 or c = 29 or c = 30 or c = 31
)

The variable “c” is going to equal the numeric representation of the keyboard key.

The line starting with “Length” is checking to see if the key was a number, a period, and if the script parameter is the word “dash” then the dash, too.

As for the other codes, here’s the legend:

9 – Tab
10 – Enter (number pad)
28 – Left arrow
29 – Up arrow
30 – Right arrow
31 – Down arrow

The easiest way to tie the keyboard to a number is through the Keystroke Companion by SixFriedRice. A must-have in a FileMaker developer’s toolbox. So the script checks to see if the user hit an appropriate symbol or an appropriate keyboard key. If the user has, the script exits with a 1, meaning “OK”. If the script exits with a result of 0, the script trigger will prevent the keystroke from being executed. The cool thing about OnObjectKeystroke is that the script runs before the key is entered into the field, so the script has control whether or not the key shows up.

Clean. Elegant. User friendly.

The nice thing about implementing script triggers like this is that the user gets feedback on what’s right or wrong when entering data. One approach is from a preventative perspective, while the other warns the user when something needs to be fixed. It’s these types of techniques that can really make a solution clean, elegant, and user-friendly.