Returning The Cursor To A Field

I don’t know if this is a previously documented technique (if so, please let me know in the comments), but I discovered a way to handle those nasty return-to-field if statement trees that we have to build when performing finds triggered by OnModify script triggers.

Here’s the scenario:

  1. User types in a find field.
  2. OnModify script trigger runs the find script.
  3. Results are updated.
  4. The cursor is returned to the field the user was typing in, so they may continue typing.

It’s that last step in the process that’s annoying.

Right now in FileMaker 11, we have no “Go To Field By Name” script step. So to make the cursor return to where it’s supposed to be, we typically will do this:

Set Variable [ $ActiveField ; Get ( ActiveFieldName ) ] Perform Script [YourFindScript]

If [ $ActiveFieldName = “Field1” ]
Set Selection [ “Field1” ; End: 10000 ]
Else If [ $ActiveFieldName = “Field2” ]
Set Selection [ “Field1” ; End: 10000 ]
Else If [ $ActiveFieldName = “Field3” ]
Set Selection [ “Field1” ; End: 10000 ]
End If

Of course this works, but what if you edit field names? What if you need to add new fields? It gets pretty tedious updating this type of code.

I realized I could use one of the Design functions to make this super easy to maintain.

Add a layout to your solution that contains only your find fields. This layout can be in any file, because the design function we’ll be using calls the file by name.

My layout looks like this:

This layout contains all the fields I use for my find scripts.

Make a new script whose sole purpose is to return the cursor to the appropriate field. I called mine, “Return To Field”.

NOTE: Any find script that calls the Return To Field script must have this step at the beginning:

Set Variable [ $ActiveField ; Get ( ActiveFieldName ) ]

My find script:

My find script. Note that the key field Users::zzk_DataListRecordNumbers is actually a return-delimited list of numbers representing the number of records I want to see in my virtual list.

Once we know what the active field is, and we’ve performed whatever script we want to, it’s time to take the user’s cursor back from whence it came.

I use a custom function called TrimMV, which stands for Trim Middle Values. The purpose is to remove the trailing return from the MiddleValues function. It looks like this:

If you can’t (or don’t want to) create a custom function, you can use the entire function calculation in place of the TrimMV statement.

Here’s what my Return To Field script looks like:

This is the script that returns the cursor to the active field

Here’s the script text for one of the If/Else If statements (they’re all the same):

If [ Let ( $Count = $Count + 1; $$ActiveField = TrimMV ( FieldNames ( “Users.fp7” ; “Interface Data” ) ; $Count ; 1 ) ) ]

…where “Users.fp7” is the file in which my find fields live, and “Interface Data” is the name of the layout on which the find fields reside.

Notice that if I want to add a field to the mix, I simply duplicate an Else If/Set Selection pair (as highlighted). The ONLY thing I have to change is the field name in the set selection step. This is because each time the script encounters the Let ( ) statement in the If or Else If steps, it increments $Count, and this causes the value returned by TrimMV ( ) (the MiddleValues ( ) function, to be precise ) to be different than in the previous If/Else If step.

If the field names change, it doesn’t matter. The FieldNames ( ) function will pick that up. If you add a field, be sure it’s added to the script in the order it’s found in the FieldNames ( ) function (alphabetical)**. That’s super important, so I’ll say it again: Your Set Selection [ ] results need to follow the order of the field names as seen in FieldNames [ ] !

This method allows me to use one script for all return-to-field moments, with the least amount of effort.

Give that a try and see if that simplifies your life a little bit.

**UPDATE: 03/30/12 1:55 pm On further review, it looks like that the field order is not alphabetical, but creation order instead. Sorry for the confusion!

UPDATE 2: 4/23/12 11:05 am – While working with the FieldNames function while testing the XML Fields custom function, I found out that the order of the fields returned will be the order that they were put on the layout. That’s super handy if it’s true. I’ll have to test it in this scenario as well.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s