Windows don't work the same in FM GO as in FM Pro. For one thing, you can only see one window at a time and it fills the display.
Don't know if that's an issue here or not, but Go to Layout hasn't shown me any issues in FM GO 15 on my iPhone...
Does a new record get correctly created in the right table by this script?
I'm pretty sure the new document window is your problem.
Can you skip the new window if the get(systemplatform)=3? I suspect you will have better results.
Ok. I'll rewrite it to not open a new window in Go15.
I have used this method dozens of times in Go 12 and Go 13 with no issues.
Not sure why but I liked the way I could open a new window for minor interactions and data input and then have a "Back" button on the layout that simply committed the data and closed the window. Then the user was right back to where they left off. Are you thinking that Go 15 doesn't have this functionality?
Please answer my questions.
Did the changes get made but you just don't see the expected window?
If so, you may just need to include a "select window" step in your script to select the new window so that it's not hidden behind the other.
One reason for the new window method is to leave the current window and focus unmodified by your script so that a user can return to where they were--with even a portal still scrolled to the correct location.
There's another method for creating new related records that has the same advantage, but does not require opening a new window nor changing layouts. You might research MagicKey and see if that suits your needs here.
I'm sorry, I forgot to answer the question.
The changes did not get made and the new record request was not executed.
The script appears to just stop at the Open New Window step.
Do you know if the new window step executed? On iOS, the new window will look almost exactly like the original if there's no layout change. you might need to tap that small downward pointing triangle in the window title bar to see if you have one window open or two....
Are you sure that you don't have a layout based script trigger on either of these two layouts?
I made sure there were no layout script triggers on either layout. The new window definitely opens on Go15. I can click the name of the host at the top of the Go15 app and see all the windows that are open. It is opening properly, it just opens to the same layout I just came from and it does not appear to execute any further steps in the script beyond the open new window step.
What you are using is a very common method of creating records though I prefer a different one myself in most cases. I'd think that we'd be inundated with trouble reports if this were an FM GO 15 bug, but you are welcome to post this over in the Report an Issue section to see what the TS people have to say about it.
If I were you, I'd create a brand new file with just a few fields and two related tables, then try to reproduce this behavior in that new file.
You might also insert a bunch of Show Custom Dialog steps between every script step after New Window to see which execute and when while testing it on your iOS device--how we used to debug on FM Pro before we had a debugger...
I'm sorry for wasting everyones time. I found what the problem was. I confirmed there was no automatic script triggers on the new ServiceReport Layout but failed to look on the original layout, Inventory. When the new window opened the "layout enter" script trigger ran and appears to have canceled the rest of the scrip to go to the correct layout and open a new record.
My time was not wasted.
This is a familiar "gotcha". it's not really intuitive that opening a new window--which opens to the same layout as that which is "current" for the active window, trips that particular trigger so you are not the first to be caught by that one.
This is one of the reasons for using MagicKey. You never leave the layout, open a new window or any other action that changes focus and thus no triggers can be tripped.
One way to keep trigger performed scripts from interfering when your script does something that might trip such a trigger is to include this code at the top of every trigger performed script:
If [ $$TriggersOff ]
Then you can have any other script disable triggers by setting this global variable to True before doing anything that might trip a trigger. Just be careful to set the variable back to False or "" before the script exits so that you don't leave your triggers disabled when the script exits.