Change the tab order so that a layout object that is not a field (such as a button) is the first object in the tab order.
Seemed like a good bet, but it doesn't work. The first field object in the tab order opens. I tried switching tab orders to confirm this.
Interestingly, in a different script, the field doesn't open.
The difference seems to be that one is launched by an field modify trigger, and the other is launched by a button. Opening the field for editing seems to be a result of the trigger field closing. Even adding a commit step at the end of the script doesn't stop it.
Putting the cursor in the field should "open it for editing".
What I am suggesting is to make a button the first item in the tab order instead of the field. That should keep the cursor from being dropped into the first field like this.
A script can also use Go To Object to put the focus on a button or other named layout object.
I did try changing the tab order as suggested, but it did not work in this case. I cleared out the tab order, and assigned only five items, the first being a button. Upon completing the script, focus jumped to the second item in the tab order, skipping the button. I'll give the Go To Oject idea a try when I'm back home.
Did a bit more investigation. Perhaps some background is in order...
I have a number of projects on the go at once, so I use a field on most layouts that has a drop-down list of all the projects active in the solution. When I choose a value from that list, it goes to all the related records for that project, based on the new value.
In the desktop version, choosing a value exits that field and momentarily throws focus to the next field in the tab order (#1), but the first script step is a Commit, so the record is then saved and the field closes. The rest of the script executes, and then I'm presented with a new found set, and no field open for editing.
In the Go version, using the same script, I end up with field #1 open for editing. This happens even if I:
> use OnObjectSave to start things off
> specify a non-editable object as #1 in the tab order (in which case the next editable item in line will open)
> use Go To Object (a non-editable one) at the end of the script
> end the script with a final Commit
I use this technique on several layouts, with the same results. Honestly, on the iPad, it's more of an annoyance than anything else, because of the size of the screen. However on the iPhone, opening a field for editing brings up a keyboard, or date or time scroller, which obliterates a huge chunk of visible data.
I have found two ways around it:
> If I create a button to modify that initial field through the use of a custom dialog, and then kick of the script with the new value in place, no problems. This is not a great solution, since it requires me to type in the project name on the weeny iPhone keyboard, rather than select it from a list.
> I empty the tab order, however, then I lose the ability to use Next and Previous when editing (the same field reopens).
The problem seems to be related to use of OnObjectModify (or OnObjectSave) in Go that triggers a jump to the next field, and that trigger persists through an entire script, through multiple Commits.
That's as far as I've gotten so far.
Thank you for your posts.
Please post your script so others can get a better understanding what is occurring.
In a simple script, using "Go to Layout" should not put the cursor into a field for editing. Is there a script trigger for the Layout? That is, do you have "OnRecordLoad" or "OnLayoutEnter" selected?
Here you go. It's a simple script that refreshes the screen with a new set of related records. There are no layout script triggers, either coming or going.
Go to Related Record [ From table: “ShowReports by Show”; Using layout: <current layout> ] [ Show only related records ]
Sort Records [ Specified Sort Order: ShowReports::Date; ascending ShowReports::Unit 1 start; ascending ] [ Restore; No dialog ]
Go to Record/Request/Page [ Last ]
Set Field [ Environment::gReportsLastViewed; Get ( LayoutName ) ] )
The way this works is as follows: I click on a field with a drop-down menu, and the new value becomes the source key used in the relationship. When running on Pro, it ends with a new found set, but no fields open for editing. When run on Go, it ends with a new found set, and the first editable field in the tab order open for editing.
However... If I alter the source field value through a custom dialog (i.e. do not open that field) and then call the script, I don't have the problem in Go. Also, if I completely clear the tab order, there is no problem.
The conversation seems to have lapsed.
I'll flag this as an issue in GO and hope it is rectified someday.
Sorry for the late reply.
I am unable to replicate the problem using a similar script. After committing the record and setting a field, my cursor does not appear in any field, no matter which field I was editing. It may be easier if you send in a sample file so I can determine why this is failing. Check your Inbox at the top of this page for instructions where to send the file.
Done, and thanks for any help.
I received your file. Thank you.
Yes, the script trigger for OnObjectModify does act differently between FlleMaker Pro and FileMaker Go, where in FileMaker Go, the OnObjectModify script finishes and then proceeds to the next field. Therefore, a workaround is to set a global flag and then set a OnObjectEnter script for the next field and check for the flag.
Using the example you sent, create a Text field, "Flag", for global storage. As the last step of your existing script, add:
Set Field [ Flag ; "1" ]
Then, create a script, "Show Name entry", with the following script steps:
If [ Flag = "1" ]
Set Field [ Flag ; "" ]
Commit Records/Request [ No dialog ]
For the "Show Name" field, create a script trigger for OnObjectEnter to call "Show Name entry". When the cursor enters that field, the "Flag" field is checked, and if true, the "Flag" field is blanked out and the record is committed.
I have sent my findings to our Development and Testing departments for review and explanation. When I receive additional information, I'll let you know.
Thank you for the suggested workaround. I had tried something similar by adding a commit at the end of the script, but apparently the queued "next field" instruction persists beyond the end of the script. Your backstop will do the trick, but I hope this can be rectified in a future update. As noted, this is not an issue for pop-up fields for some reason.
Hmm, why not use a global variable for flag? $$Flag would seem to work just as well and you can then avoid adding an extra field just to work around this one bug.
Go has an annoying habit of leaving the cursor in the field after using the keyboard and perhaps this is your problem. Personally I would prefer that when we close the keyboard the record is commited and the field exited as part of Go's programming.
The cursor remains in the field in Filemaker after selecting, editing, etc without too much of an anoyance so the problem for me is just the size of the expanded field which is designed into Go and is not related to anything we do for formatting.
Reading your script above I see you do what so many Filemaker scripters do, avoid using Commit Record after a Set Field. Try adding a Commit Record after your Set Fields... Almost always I get a response, Filemaker does this for me...