onLayoutExit and Layout navigation…something strange

[Bailey Kessing]

It is late at night and maybe I shouldn’t be posting, but I can’t get this to work the way I think is should. Users are requesting a “Back” (and “Forward”) button. We all know that they won’t work “exactly” like a web browser, but they still want it. What I did was use the “onLayoutExit” script trigger to set the variable $$layout to the Layout Name (or ID). Then I have a “back” button/script that says Go to Layout "$$layout”…simple right? Well, my little brain can’t get it to work. The layout recorded is the Layout that I go to not the one exiting from. So the “back” is the same layout. Uhg. Why is this? Feeling dumb and frustrated…especially if a bug!

[LaRetta]

So you are exiting the layout and it uses the current layout when the button should actually use the prior layout. I see what you mean, Bailey. Do you use script to leave the current layout at all during the User session?

[LaRetta]

I did what I should have done originally - I ran it through debugger. It is because the button fires but the layout does not switch until the script trigger fires. It fires and produces the current layout name.

You might consider writing the layouts to a multiline upon entry to the layout. Be sure to include a method of setting a $DEV flag so it does not run as you move around during a script where Users do not go. ;-)

[comment]

What am I missing here? I cannot reproduce the issue. A script triggered OnLayoutExit runs before the event - therefore Get (LayoutName), when evaluated during script runtime, returns the name of the "old" layout (the one being exited).

[Bailey Kessing]

Yes, it should. But I don’t see that. I see that I trigger the script to store the layout on OnLayoutExit (as you describe) and that when I hit run a script on the “current” layout to go to the stored layout it doesn’t because the “current” layout is actually stored…that is what was bothering me. WHy should that be? What am I missing that you are not? Still feeling really dumb at the moment…perhaps more coffee.

[Bailey Kessing]

I have attached a file demonstrating the problem I think

OnLayoutExit.fp7.zip

[comment]

How about this way?

OnLayoutExit2.zip

[Bailey Kessing]

That does work, of course, thanks. But why doesn’t the “simple” one work…it seems it should given how things are executed right?

[comment]

why doesn’t the “simple” one work…

It does work - only not quite the way you would expect, being a human. A computer, OTOH, is much more literal - and Filemaker takes the "evaluated at runtime" part very literally:

Suppose you are now at layout "B" and $$previousLayout is "A". When you say you want to Go to Layout [ $$previousLayout ], Filemaker evaluates the expression $$previousLayout as "A" and concludes this will require exiting the current layout "B". So the step is put on hold because the OnLayoutExit script has to run first (and if it returns False, the requested trip will be denied altogether).

Once the OnLayoutExit script has run, Filemaker returns to the marked spot and continues from there. The next thing to handle - you guessed it - is the script step Go to Layout [ $$previousLayout ] which is now approved to execute. And the way to execute it begins with evaluating the expression $$previousLayout - which now returns "B".

[LaRetta]

It is because the button fires but the layout does not switch until the script trigger fires. It fires and produces the current layout name.

I guess my explanation was too concise, LOL.

[comment]

I guess so - I had to read it three times (now) to understand (maybe ) what it means.

The interesting part here is that the calculation inside the Go to Layout [ calculation ] is evaluated twice.

[Bailey Kessing]

Yeah, I guess I would have said the literal and logical would be that the go to is “set” into motion and once exiting the layout executed it is after the go to…so not affect it. Oh, well. Seems wrong, but who cares. Have the workaround and am off and running. thanks.