Set a script trigger on the field for OnObjectKeystroke, and attach a script with Code ( Get(TriggerKeystroke) ) = 13 as an If statement. Then, based on what your user types, it will or won't trigger whatever script you tell it to.
for some reason that didn't work but I'm going to try again
Try as suggested but with the layout script trigger "OnLayoutKeystroke" and attach the script
If [code (Get(TriggerKeystroke)) = 13 orCode (Get(TriggerKeystroke))=10
Perform Script ["Find from global..."]
NOTE: code 13 is Carriage Return; code 10 is Enter Key
The only downside to using an OnLayoutKeystroke is that it's going to trigger the script regardless of where you are when you press return. If there are other fields on the layout, text fields that can have carriage returns in them, or fields that use return to move to the next field, this script will be triggered when used. If that's not a concern, then OnLayoutKeystroke is fine. Otherwise, she should stick to OnObjectKeystroke so that it's only activated from the global search field and won't interfere with the use of Return in other fields.
How about OnFieldExit trigger? And set the field to tab on Tab, Enter, and Return.
And have the triggered script exit without running anything if the field is empty -- no find request entered.
Or have it pop up a message saying the request field is empty so they know that's what happened.
One way to do this, which hasn't been mentioned so far, is to use an "OnObjectModify" trigger. It's easier to work with than a layout trigger. Basically, as they type each letter in the global, you trigger a script that performs a find based on what they've typed so far, and then re-enters the global field. If the find is indexed it happens very fast. It has a whiz/bang effect as it actively filters the list as they type. It has the added benefits of not having to delve into the code/char functions, or having to click past layout and record triggers constantly in the debugger.
One gotcha is to have the field NOT be set to "Select Entire Contents on Entry." if you want this feature on for when they click into the field, you can do by capturing the loction of the cursor in the field and going back to it - or other methods - but it's really easy if you don't check the option in the first place.
I am just playing with exactly that solution.
There is only one issue which I could not solve: the Enter key on windows.
- It gives the code 10 on Mac
- It gives the code 5 on Windows 8 (running on Parallels Desktop)
- It gives the code 13 on Windows (the issue which I am testing).
The Filemaker manual only gives 10 as a result for the Enter key. It also notes there are 2 windows keys named "Enter", and only the one on the numeric pad is the "real" thing (should respond with code "10").
Do you have any experience on Windows with the Enter key?
[edit: uploaded the example file directly here to this community, see below]
I don't know about running Windows 8 on Parallels, but Mac and Windows both distinguish between "Enter" and "Return". There's no difference to the lay user, but for historical and technical reasons they're different and both accessible on either platform.
As breezer mentioned above, just trap for any of the codes.
Thank you, David
That is what I expected. However, clients give different feedback. And as the clients are at home in different countries, it's hard "to look over their shoulders". I started investigating and found a remark that Filemaker Pro 12 did not recognize the enter key properly under windows – a year ago. Anyway, the feedback is helpfull, in that it confirms that it should give back the same codes on all platforms:
Return = 13
Enter = 10
Strange though, that Windows 8 on Parallels has a different feedback on that code, as it probably is emulated.
You may be encountering issues because of your international users. I don't really know much about unicode or foreign systems, but you could check to see which users are reporting a problem (or capture it behind the scenes in your database) and see if there's a correlation to country.