FileMaker Addict Has Moved!

FileMaker Addict can now be found here: http://www.filemakeraddict.com




Saturday, January 10, 2009

FileMaker Pro 10: Putting Script Triggers to Work

One of the most exciting new features of FileMaker Pro 10 is Script Triggers, which provides us with a way to handle events. For example, we can automatically run scripts when a user changes to a new layout, when a field's value has been changed, when a record has been committed, and so on.

In this article, I'll show you how I am using Script Triggers to log changes to records. This is a fairly common request that I get from clients. It is one thing to keep track of who created a record, when they created it, who last modified it, and when they did so -- we've been able to do that for quite some time using Auto-Enter fields. But with Script Triggers, we are now able to track the actual field values as well.

As the basis of this example, I am using the sample Contact Management database that is provided as a template with FileMaker Pro 10. This is a fairly basic solution, which keeps track of contacts and allows the user to attach notes to each contact.

Our goal is simple: When a new contact is created or an existing contact is changed, we'd like to attach a new note to the contact that lists all of the fields and their values. So, by looking through the notes, a user will be able to see detailed information regarding how the record has changed over time.


Developing the Script

The first thing that we will do is create the script that will run when a record is created or changed. The script that I wrote (titled "Contacts - Trigger - Log Record Commits") looks like this:

[ 1] #Grab the ID of the contact.
[ 2] Set Variable [ $ID_Contact; Value:Contact Management::k_ID_Contact ]
[ 3] #
[ 4] #Get the field names and values of all fields on the layout.
[ 5] Set Variable [ $FieldNames; Value:FieldNames ( Get ( FileName ) ; Get ( LayoutName ) ) ]
[ 6] Set Variable [ $Audit; Value:"Audit Information..." ]
[ 7] Set Variable [ $i; Value:1 ]
[ 8] Loop
[ 9] #Ignore fields that are from related records.
[10] If [ PatternCount ( GetValue ( $FieldNames ; $i ) ; "::" ) = 0 ]
[11] Set Variable [ $Audit; Value:$Audit & "¶" & GetValue ( $FieldNames ; $i ) & ": " & GetField ( GetValue ( $FieldNames ; $i ) ) ]
[12] End If
[13] Set Variable [ $i; Value:$i + 1 ]
[14] Exit Loop If [ $i > ValueCount ( $FieldNames ) ]
[15] End Loop
[16] #
[17] #Create the note.
[18] Go to Layout [ “Notes_Utility” (Notes) ]
[19] New Record/Request
[20] Set Field [ Notes::kf_ID_Contact; $ID_Contact ]
[21] Set Field [ Notes::Text; Notes::Text & "¶" & $Audit ]
[22] Commit Records/Requests [ Skip data entry validation; No dialog ]
[23] Go to Layout [ original layout ]


Here's what the script does:

On line 2, we grab the ID of the contact that has either been created or changed. We need to do this so that we can attach the note to the correct contact.

Next, we need to grab both the names of all of the fields on the layout, as well as all of the field values. Before we do that, we need to do some prep work. On line 5, we store the names of all of the fields in a variable named $FieldNames, and we do this using a combination of the FieldNames, Get ( FileName ), and Get ( LayoutName ) functions. On line 6, we initialize a variable named $Audit, which we will use to build the contents of the note. On line 7, we initialize another variable ($i) which we will use to keep track of where we are as we loop through the list of field names.

With all of the prep work out of the way, we're ready to loop through the list of field names. The loop starts on line 8 and ends on line 15. On line 10, we check to see if the name of the field has two colons in it. If so, then this is most likely a field from a related record, and we aren't going to include these in our audit info (although you certainly could if you wanted to). Line 11 appends the name of the field and the field value to the $Audit variable that we set earlier -- and we use the GetValue and GetField functions to get this information. Line 13 increments our pointer variable ($i), moving us to the next name in the list of field names. Line 14 checks to see if we're at the end of the list of field names, and if so, we want to exit from the loop.

The final step is creating the note itself. On line 18, we jump to the Notes_Utility layout, and on line 19 we create a new record. Line 20 sets the "kf_ID_Contact" field with $ID_Contact, which essentially creates the link between the contact record and this new note record. Line 21 sets the "Text" field with the the audit information that we've just built up into the $Audit variable. On line 22, we commit this new record. And finally, on line 23 we jump back to the original layout and display the contact.


Setting Up The Script Trigger

With the script in place, we're now ready to use it . To do so, we go to the Contact Management layout, enter Layout mode, and select "Layout Setup..." from the Layout menu. A new tab on this dialog box is titled "Script Triggers" and that's where we'll setup the trigger.

The event that we want to attach our new script to is "OnRecordCommit." This event occurs whenever an attempt is made to commit record changes via this layout. This includes commits of both new records and existing records. Note that, in the case of commits to existing records, if no data has changed and the user attempts to commit the record anyway, then the event does not occur.

Using the Layout Setup dialog box, we attach the script to the event. See below.




Testing

Go ahead and test the new script trigger by creating new records and making changes to the existing records. When you do so, you should see that new notes are automatically created that include the audit info. Here's an example:

1/10/2009 9:40:38 am by Tim Dietrich

Audit Information...
Street2:
Address_Type1:
Street1:
City1:
State_Province1:
Postal_Code1:
Address_Type2:
City2:
State_Province2:
Postal_Code2:
g_Similar_By: Name
Name_First: Timothy
Name_Last: Dietrich
Phone1: 703-555-5555 x100
Phone2:
Email: tim@xgravity.net
Instant_Messaging:
Title:
Company: Xgravity
Website:
Image_Data: TimDietrich - Forum Pic.jpg
UserName_Created: Tim Dietrich
Date_Created: 1/10/2009
UserName_Modified: Tim Dietrich
Date_Modified: 1/10/2009



Conclusion

This is a great example of how to use the new FileMaker Pro 10 Script Triggers functionality. However, please keep in mind that there are a number of other events that you can attach scripts to, so let your imagination run wild and I'm sure you'll quickly find a number of other practical uses for this new functionality!

Monday, January 05, 2009

FileMaker Pro 10 Is Here!

FileMaker Inc officially released FileMaker Pro 10 this morning! Here is a summary (with screenshots) of some of the new features in FileMaker Pro 10 (the client version):

Script Triggers
At long last, with FileMaker Pro 10 we have native support for running scripts when events occur. Sure, for several years now we've had plug-ins available that can provide this type of functionality. But with the functionality built into FileMaker directly, we no longer have to worry about managing the plug-ins, and I suspect that the functionality will be much more stable as well.

Script triggers can be setup to work at the following levels: at the layout or record level, at the layout object level (fields, for example), or at the file or window level. Triggers can be setup to behave differently depending on options that are set. For example, a script trigger associated with a layout might behave one way when the layout is in browse mode, another way in find mode, and so on. Also, depending on the script trigger, the script that runs does so at different times relative to the triggering event. For example, when changes to a record are about to be committed , a script can run before the actual commit occurs, instead of the commit occurring, or after the commit occurs. Scripts that run before an event can return a values that indicates whether or not the event should be processed.

A complete list of the script triggers supported includes: OnObjectEnter, OnObjectExit, OnObjectModify, OnObjectKeystroke, OnObjectSave, OnObjectKeystroke, OnObjectSave, OnLayoutLoad, OnLayoutKeystroke, OnModeEnter, OnModeExit, OnRecordLoad, OnRecordCommit, OnRecordRevert, OnFileOpen, and OnFileClose.

To help developers implement script triggers, two new Get functions have been added. Get(TriggerKeystroke) returns a string which contains the character(s) which caused an OnObjectKeystroke or OnLayoutKeystroke script to be run. Get(TriggerModifierKeys) returns the state of the keyboard modifier keys as they were when the script was triggered.

Of all of the new features included in FileMaker Pro 10, Script Triggers is the one that I'm most excited about. I plan on covering Script Triggers in greater depth in a future blog post.







Status Area Redesign
Perhaps the biggest change in FileMaker Pro 10 -- and I believe the one that will be the most controversial -- is the change to the user interface, particularly the redesign of the status area. The status area, which has always been displayed vertically and to the left of the screen, has been moved to the top of the screen and broken into logical sections.

FileMaker indicated that it had four primary goals in making this significant change to the UI: To make the interface look more modern; to give users an easy way to switch between modes; to make key functionality more accessible and prominent; and to continue to provide access to functionality that was previously accessible in the status area.

It will be interesting to see how FileMaker users react to this change!




External SQL Server (ESS) Enhancements
There are a few ESS-related enhancements that have been made in FileMaker Pro 10. You can now use fields from ESS tables as the basis for value lists. Also, support for Microsoft SQL Server 2008, Oracle 11g, and MySQL Community Server 5.1 has been added.


Sub-Summaries In Browse Mode ("Live Reports")
Ever wish that you could see sub-summaries in something other than Preview mode? With FileMaker Pro 10, that's now possible! You can now see sub-summary parts when in List or Table View. Best of all, using the new "Maintain Record Sort Order" (another of the "Top 10 New Features in FileMaker Pro 10" and described next), you can give users the ability to make changes to their report data and instantly see the impact of the sub-summary info. Think of this as "Live Reports."

Also included in this feature is the ability to add or remove fields from the display when in Table View -- without having to jump back and forth between Layout mode. When making changes to the fields included in Table View, the layout itself doesn't change. In other words, the fields displayed in Table View are no longer dependent upon the fields on the layout itself.




Maintain Record Sort Order
Have you ever sorted records in a found set, made changes to those records that caused the records to no longer to be sorted properly, and wished that FileMaker would automatically re-sort them for you? With FileMaker Pro 10's new "Maintain Record Sort Order" that is now possible. In fact, you don't even need to do anything -- other than sorting records in the first place -- to make this feature come to life!

There's a lot more to this feature that you should be aware of. For example, how it behaves when records are imported, or what happens when records in your found set are changed by another user. In the future, I'll cover this feature in greater depth as well.


"Set Field by Name" Script Step
In the past, in order to indicate which field you wanted to be set, you had to use the Set Field step and select a from a list of available fields. This new script step lets you dynamically specify the field that you want to be set by using a calculation. How might you use this? Imagine passing in the name of a field to a script as a script parameter, and then using the Set Field by Name along with the Get(ScriptParameter) function. You could write a single script that could be used to change any field that you specify when you call it.


Import and Export With Excel 2007/2008
With FileMaker Pro 10, you can now easily import and export data in Excel 2007/2008 format. This is a welcomed relief for those of us who regularly need to send data -- or receive data -- from users of the more recent Microsoft Office suites.


Bento Integration
Based on the huge success that FileMaker Inc. has had with Bento (the personal database solution available to Mac users), it is not surprising that FileMaker Pro 10 now includes a way to share data between the two programs. Data can be imported from Bento into FileMaker, and Bento is listed as an option in the File / Import Records dialog box.



Saved Find Requests
This is an interesting feature which gives users the ability to save a find that they just performed. All find criteria are saved, regardless of their complexity. A user's saved finds are personal (meaning that other users cannot see or share them), and the finds are saved in the database itself (so that a user can access their saved finds regardless of what machine they are using).




SMTP-based Send Mail Option
With FileMaker Pro 10, we can now send mail via an SMTP mail server without the need for a plug-in. In the past, the only way to send mail from FileMaker natively was to use a local email client.




There are a number of other new features in FileMaker Pro 10, including:

  • Save Target Printer: Mac users will be glad to hear that the Print script step now "remembers" the printer that was targeted when the script was written. Windows users have had this ability for quite awhile now, and according to FileMaker Inc, this was a feature that slipped in quite by accident. 
  • Code and Char Functions: New functions for dealing with Unicode characters.
  • ESS DATETIME Flexibility: You can now change the data type of ESS shadow fields that are based on a Microsoft SQL Server DATETIME (as well as SMALLDATETIME) columns.
  • ESS Single Sign-On: Windows users can now access ESS datasources via "single sign on."
  • Improved File Recovery Function: Changes have been made so that the default settings used when recovering damaged files are more likely to work properly.
  • Support for IPv6: It has been predicted that we will "run out" of IP address sometime in the next year or two. At that point, we will need to switch to the next version of the Internet Protocol (known as "IPv6"). FileMaker Pro 10 is now ready to go when this change is necessary.
  • Old File Formats Dropped: Some of the older file formats, including Lotus DIF (.dif), Lotus 1-2-3 (.wks), Symbolic Link (.sylk), Basic (.bas), and dBase II and III (.dbf ) have been deprecated.
  • More Font Sizes: Additional common font sizes have been added to the font size menu.
  • Tab Order Enhancements: You can now add objects into the middle of a layout's tab order.

What are your favorite new features in FileMaker Pro 10? What's still missing that you just can't live without? Let us know what you think.

I'll cover changes to FileMaker Server 10 soon, so stay tuned.