What’s in a name? A story about Go To Object

This is a story about how naming my objects (fields, buttons, etc.) in FileMaker had me scratching my head for a bit because my ‘Go To Object’ script step did not do what I expected it would do.

Our story begins here – As we all know you name an object while you are in layout mode:

I do this for my first two fields, naming them ‘field01’ and ‘field02’, respectively so that I can have a script with this script step.

As a result, the cursor will end up in the field with that name. You can see that the field is properly highlighted and the cursor is inside the field ready for anything the user wants to type in.

So far, so good. Now I decided that I wanted to add a button action to the field. I right-click the field, make it into a button, and assign it a script that will do some things. Then I use that ‘Go To Object’ script step to leave the user in the field, ready to type.

When I click the field, the script runs and it does indeed leave the user in that field. I’m happy.

But I want one more field so I duplicate that field where everything works. Because I want it to behave in a similar way (when the user clicks it, a script does some work and then leaves the user inside that field),  I duplicate the second field and change it in the Inspector to point to the field that I want.

I assign it the script that should run when the user clicks that field:

Before I forget, I must make sure that the new field has the proper name for the ‘Go To Object’ to use:

Nothing really interesting happening here. This is what we have done a million times before as we are building screens for our users.

But…. when I click that 3rd field, I can see that the field is highlighted but the cursor is not in the field and the user cannot type in it:

Which is different than what happens when the user clicks on the second field: then the field is also highlighted but the cursor is clearly in the field and the user can type:

But… since the 3rd field is an exact copy of the 2nd field, why would it behave differently!?

This is where I start scratching my head.

Turns out that there was a big clue that I missed as soon as I made the 2nd field a button — as soon as I did that, there was no more name shown in the Inspector.

So what is happening here? As soon as you assign a button action to a field, what you see in the ‘name’ on the inspector is what the name is for the button object, not the field object. The field still has its name, but you just don’t see it. Because it still has its name, the ‘Go To Object’ knows to go to the field object. And because I had not named the Button yet, the name is blank.

Once I duplicated that field and assigned it a new object name, I did not really assign that name to the field object but to the button object.  And so the ‘Go To Object’ dutifully goes to the button, not the field. That explains why it still looks like the field is highlighted but the cursor does not go to the field. It was because we did not tell it to go to the field; we told it to go to the button. And it is the button that is highlighted, not the field.

Ok, well that makes sense.

The big downside here is we now have a sort of grouping of two objects: a field and a button, each with their own name but we only see one in the Inspector. There is no way – as far as I can tell – to reveal the name of the field object again. You might be thinking: just remove the button action from the field, right? No, unfortunately that does not remove the actual button object. Rather, it just sets its action to ‘Do Nothing’, but the button object remains and so does its name.

To make matters worse, if you have a field with an object name, and you are thinking of making it a button so you bring up the “Button Setup” dialog but you change your mind and just close the dialog box, you still end up with a button object with its own name (blank by default):

Moral of the story

Be careful assigning button actions to other objects, especially if you want to target the original object by ‘Go To Object’.