How can I use the let function to set a $localVariable?

[jbante]

 I'm afraid you misunderstood me (or I you). Filemaker does any one of the three options, depending on how you set this up.

 

In my testing, I only got FileMaker to do option C. Josh has demonstrated A. Can you demonstrate a circumstance where FileMaker does B? The important thing is whether FileMaker's behavior makes layout-set merge variables usable. For A and C, the answer is yes, we can work with that. B is the only problematic situation, but I haven't seen it yet, despite my attempts to find it.

 

I am not sure how that will work, given that before the script exits, the script is still running...?

 

I should have said that the script needs to set the variable or trigger a refresh itself before exiting to create the appearance of the layout resetting the variable.

[Josh Ormond]

You get A when nothing in the script refreshes the window. You get C when something in the script does cause a refresh or redraw. Adding a simple Freeze window to a script will then cause C to happen in my file.

[jbante]

After some more testing, I think I have a slightly more coherent and comprehensive idea of the interaction between variables set by layout and by script. I created a counter that increments itself in a Hide Object calculation. It increments on its own when switching modes (by 1) or when refreshing the window (by 2, therefore, by 1 twice) without a script. When a script starts, the value of the counter variable is apparently empty, and starts re-counting from 0 when the window is refreshed during the script. When I refresh the window again after the script, the counter resumes from where it left off before the script started.

 

Another variable is set to different values by the layout and the script, but the calculation in the layout respects any previously set value if it finds one. This variable shows the value set by the script during and after the script, but reverts to the value set by the layout after a non-scripted refresh, i.e. the variable set by the script is gone. (Duh.)

 

Another variable set by a calculation in the layout completely ignores its previous value. When the script sets that variable and refreshes the window, the value from the layout displays in the layout, and that value is then also what the script sees.

 

This suggests that a layout-scoped variable persists during the script, but the script-scoped variable takes precedence during the execution of the script. However, when the script refreshes the window, the layout has an opportunity to set script-scoped variables, and those variables are then available to the script. After the script exits, the original layout-scoped variables are available again.

 

Interestingly, if the script sets variables and doesn't refresh the layout, the GetLayoutObjectAttribute function can still return what it thinks the contents of a layout object ought to be, rather than what's actually being displayed, which I'm reporting as a bug.

LocalMergeVariableTest.fmp12.zip

[comment]

In my testing, I only got FileMaker to do option C. Josh has demonstrated A. Can you demonstrate a circumstance where FileMaker does B?

 

I don't know of a good way to demonstrate B using a variable that's populated by a layout-related event. Your latest crop of findings summarizes the situation quite well, though. I would just add one or two points:

 

 

This suggests that a layout-scoped variable persists during the script, but the script-scoped variable takes precedence during the execution of the script.

 

The term "layout-scoped variable" is misleading, IMHO. Local $variables are not layout-scoped. If anything, they are script-scoped. In this context, the concept of "script[0]" that Ray Cologon presented for the set of variables declared while no script is running, may be useful.

 

Also, when you say that "the script-scoped variable takes precedence", it suggests that you need the script to actually declare a competing variable in order for the non-script variable to become suspended. That's not so; all local $variables that weren't declared during the runtime of the current script are put aside for the duration.

 

 

if the script sets variables and doesn't refresh the layout, the GetLayoutObjectAttribute function can still return what it thinks the contents of a layout object ought to be, rather than what's actually being displayed, which I'm reporting as a bug.

 

I am not at all convinced that's a bug, or even undesired behavior. If there's a legitimate grievance here, it should be directed at the entire gap between what Filemaker holds as "the next screen I am going to draw" and what's currently in the graphic card's buffer - not just one detail out of the entire picture. If you're willing to accept Filemaker's paradigm as a lazy application that skimps on window refreshing (and now even more so with Refresh Object []), then you should have no quarrel with this particular aspect of it.

[jbante]

I am not at all convinced that's a bug, or even undesired behavior. If there's a legitimate grievance here, it should be directed at the entire gap between what Filemaker holds as "the next screen I am going to draw" and what's currently in the graphic card's buffer - not just one detail out of the entire picture. If you're willing to accept Filemaker's paradigm as a lazy application that skimps on window refreshing (and now even more so with Refresh Object []), then you should have no quarrel with this particular aspect of it.

 

I just did a test now, and found that this behavior-that-I'm-calling-a-bug works the other way, too: when a script sets a local variable displayed on a layout, refreshes the window, and exits, the GetLayoutObjectAttribute function result reflects what the layout would set, even before the layout actually displays it.

 

I endorse lazy evaluation as it is understood in other programming contexts, e.g. FileMaker's boolean logic short circuiting. FileMaker's behavior here isn't quite that; it's pre-emptive rather than reactive. I expect the GetLayoutObjectAttribute function and other design and state functions to tell me what currently is, not what may or may not ever be. One could claim that "what currently is" refers to the next screen FileMaker anticipates drawing rather than what's currently displayed, but the latter is too obviously the more sensible choice.

[comment]

this behavior-that-I'm-calling-a-bug works the other way, too: when a script sets a local variable displayed on a layout, refreshes the window, and exits, the GetLayoutObjectAttribute function result reflects what the layout would set, even before the layout actually displays it.

 

It seems to me as the same way, not the other way. But I guess it's relative to one's point-of view - as is this:

 

One could claim that "what currently is" refers to the next screen FileMaker anticipates drawing rather than what's currently displayed

 

The way I (and Filemaker) see it, Filemaker is the one (and the only one) who has the full picture of "what currently is". From time to time, Filemaker will push the current picture to the screen. This is strictly a one-way street, a fire-and-forget missile. IOW, the screen represents "what was a moment ago". What you are asking for is a massive change in concept - it would require Filemaker to keep track of two pictures instead of just one.