Where have we been, you ask?
Happy new year. It certainly is a happy one for Proof. After 2 years of being restricted by agreement from working with the schools and people that we all had built relationships with over our many years at inResonance, we are now finally free to reach out and reconnect.
On why Google Maps doesn’t work on Mac
A couple weeks ago, I wrote an article on mapping a single address using the Google Maps API in FileMaker. It concluded that the the obvious technique, simply building a correctly-formatted JavaScript page and displaying it in the Web Viewer with a data:url, wouldn't work on MacOS X. In this article, I'd like to delve into the technical reasons I this doesn't work. Read on if you're so inclined...
Script Triggers: Using Layout Triggers for a Dynamic Tab Orders
If you’re a male, do you really need to be asked you if you’re pregnant when you are at a clinic? If your female, do you need a prostate exam? Probably not. There are little nuances to data entry that occur with just about every solution that make it just slightly more tedious to collect information with just a standard tab order. We’re going to remedy that with using a simple layout keystroke trigger.
Dynamic Tab Order for FileMaker 10
In FileMaker there is only one way to navigate the tab order. This can be annoying to an end user who has to tab through a bunch of useless fields to get to the good stuff. The gender question above is a perfect problem to solve using a dynamic tab order in FileMaker 10.
Note: As Mikhail Edoshin points out, this process could be accomplished by attaching a script trigger directly to the field in question. The reason I chose to attach the trigger to the layout is so all tab order changes are centralized in one script. For instance if you had 4 or 5 different modifications to the tab order, you would still only have one script when using the layout trigger. If you were to place a trigger on each individual field you would need 4 or 5 scripts. That was really the main idea of this whole post but I left it out for some stupid reason.
Thanks for the heads up Mikhail.
A better way for our tab order to progress in our example is to just skip fields depending on which gender is choosen. Here is the psuedocode for what I think the tab order should look like:
IF the active field is Gender THEN
IF Gender = Male THEN go to the prostate question END
IF Gender = Female THEN go to the pregnancy question END
END
Finding our Key
The TAB, ENTER and RETURN as they are the three keys that filemaker uses to move to the next field.
Note: You can specify one, two, three of these keys to progress to the
next field in the Format >> Field/Control >> Behavior...
So using our knowledge from the previous article about keystroke triggers and consulting our ascii tables we know the following will return true if any one of those keys is pressed:
Let(
keyCode = Code( Get ( TriggerKeystroke ) );
keyCode = 9 or //Tab Key
keyCode = 10 or // Enter
keyCode = 13 // Retun
)
Overriding the tab order
Assuming that my table name is TEST and my field names are GENDER, PROSTATE_EXAM? and PREGNANT, we can write our script.
If[ Let( keyCode = Code( Get ( TriggerKeystroke ) ); keyCode = 9 or keyCode = 10 or keyCode = 13) ]
If[Get( ActiveFieldTableName ) & "::" & Get( ActiveFieldName ) = getFieldName( TEST::GENDER )]
If[ TEST::GENDER = "F"]
Go to Field [ TEST::PREGNANT? ]
Exit Script [Result: False]
Else If [ TEST::GENDER = "M" ]
Go to Field [ TEST::PROSTATE_EXAM? ]
Exit Script [Result: False]
End
End
End
Notice on the second line of the script we combined two get functions to determine the table and name of the field and then compared that to the result of getFieldName( TEST::GENDER ):
Get( ActiveFieldTableName ) & "::" & Get( ActiveFieldName ) =
getFieldName( TEST::GENDER )
The reason we do this is to make sure that if for some reason you ever decide to change the name of either the table or field the script won’t break.
You’ll also noticed that I use the step Exit Script [Result: False] after I navigate to each field. The purpose of this step is to reject the TAB, ENTER or RETURN key press. If we were to leave the Exit Script step out, FileMaker would process the keystroke and therefore go the the next field in the tab order after the field I just told it to go to. This would drive everyone crazy!
Once I’ve played with this technique a little more I’m sure it will prove quite useful. It definitely makes data entry a little more user friendly.
A tale of font woes in FileMaker
The recent release of FileMaker Pro 10 is very exciting. However, it got me thinking about a font problem I recently had and I began wondering if FileMaker, Inc., might have fixed the issue in the new release...
Isolate Any Record, Anywhere, Anytime and Any Context With One Script
There are some things that are easier to explain through examples. Putting the Set Field By Name script step to work is definitely one of them. It’s not a complicated process, but seeing the new Indirection capabilities that Filemaker 10 has to offer makes a much stronger impression than trying to talk through it. Also, all my introductory quips for “isolating” and “isolation” were turning out quite depressing. So, here is how we used to find a specific record, and how we can do it now.
The Old Way
For this article I’m going to assume you are using two methods that are a part of our development process. The first is multiple parameter passing (feel free to check this out if you’ve never run into it before) and the second is Safe Find. Safe Find is a script we use to safely run a find and capture any errors that occur and return them without throwing an error dialog. Here is a copy of the actual script:
So, now on to the concept of Indirection. Here is how we used to find customers using our standard naming conventions, parameter passing and error handling:
Now, here is how we find orders:
And now for something completely different. Here is how we find vendors:
By now you’re probably seeing a trend in our scripting that has driven me nuts since day one. In Filemaker 9, we had to maintain a separate set of scripts for each context that we wanted to operate in. If we want to find a Vendor, that’s one script. Find an Order? That’s a second script. Customer? A Third script.
The New Way
Here is how we can find a Customer, Order or Vendor now:
This little beauty does something that makes us here at Six Fried Rice absolutely giddy. I can call it from any layout, pass it an ID and it will isolate the record with the corresponding ID without any further hassle! It is completely context independent. Essentially we now have a single script to replace every find by ID script we have ever created. A huge part of development model revolves around using structures, systems and conventions to centralize and simplify the development process. This particular script is a perfect example of a very simple application of a very useful feature to cut out a huge amount of redundancy in a systems.
Note: This script does require that a few things are in place before hand. For one, you’ll notice that we use the Set Field By Name to set “ID” to the parameter that is passed in. This only works if you strictly follow the naming convention that dictates having a primary key field called “ID” in every table. I’ll be posting an article going much deeper into our own conventions, but for now remember that to use a script like this, you must have consistent naming conventions throughout your system or the script will not execute correctly.