On each layout exit, I set a $$PreviousLayout variable = Get(Current Layout), and I map the back button to go to layout via calculation set to $$Previous Layout. The var gets written correctly, but it refuses to go to said layout. What am I doing wrong?

$$PreviousLayout ≠ $$Previous Layout

 

FM will see these as different variables.

$$PreviousLayout ≠ $$Previous Layout

 

It's interesting how you spotted that detail - but not "Get(Current Layout)"...

 

 

@fmow:

There's not enough detail here to enable even a guess.

Between the two of you, I think you may have guessed it: check your variable names. (I'm going to assume that he actually is using Get(LayoutName) since he said the variable does get set as expected.)

 

My other thought is the timing: might it be overwriting the variable with the current layout's name when you click the Back button?

 

You might want to dig into this:

Browser Navigation

My other thought is the timing: might it be overwriting the variable with the current layout's name when you click the Back button?

 

You know, I was tempted to dismiss this without a second thought, but you are right. I remember vaguely this has come up before: the triggering event proceeds, but not as intended because something has changed in the meanwhile. The solution is to use the script parameter for specifying the target layout.

I use next/previous/first/last buttons to step between records. When it comes to layouts, I interpret those more like tasks and use custom menu items to go from one task/layout to another. For some reason I've never seen the utility of having buttons step between layouts, but that might be due to the fact that my business solution is multi-file.

A more clear phrasing of the problem is required:

 

Here's the code triggered upon a layout exit.

Enter Browse Mode
Set Variable [ $$PreviousLayout; Value:Get ( LayoutName ) ]
Show Custom Dialog [ Title: "Debugging"; Message: "The value of the variable $$PreviousLayout is " & $$PreviousLayout; Default Button: “OK”, Commit: “Yes”; Button 2: “Cancel”, Commit: “No” ]
Exit Script [ ]

And then a button is mapped to go to layout via calculation = $$PreviousLayout

 

Now when I click the back button, it triggers the script as if it exited gets a new value for $$PreviousLayout based on the current one, but stays on this layout...

 

Very strange. The timing seems to be ok, my variable since to have the right values when I want it to. 

 

 

I use next/previous/first/last buttons to step between records. When it comes to layouts, I interpret those more like tasks and use custom menu items to go from one task/layout to another. For some reason I've never seen the utility of having buttons step between layouts, but that might be due to the fact that my business solution is multi-file.

I use the exact same procedure, but I 've caved in to user requests (which seem to be very valid) that they want a quick back button, so I ve added that on the left of the navigation pop up field. 

 

Between the two of you, I think you may have guessed it: check your variable names. (I'm going to assume that he actually is using Get(LayoutName) since he said the variable does get set as expected.)

 

My other thought is the timing: might it be overwriting the variable with the current layout's name when you click the Back button?

 

You might want to dig into this:

Browser Navigation

Not really...

 

Great link, I 'd had a look at it before, but I dismissed the forward back button functionality all together. 

 

 

You know, I was tempted to dismiss this without a second thought, but you are right. I remember vaguely this has come up before: the triggering event proceeds, but not as intended because something has changed in the meanwhile. The solution is to use the script parameter for specifying the target layout.

 

Hm, this makes some sense, but I am not sure I am 100% aware of what you suggest.

Your back button should have the following script attached to it:

Go to Layout [ Get ( ScriptParameter ) ]

In the button setup, specify:

$$PreviousLayout

as the script parameter.

sure, I read a lot about it today, found something ready made, then tried out some code myself and figured out the script interrupt, or should I say conflict resolution, and so on an so forth. Thanks again for your help, much appreciated, it's a great forum btw.