kicking off a stubborn calculation

[mk500]

I'm having trouble getting a calculation to occur. Here's what I'm doing:

I have a table called "design_elements" with a repeating field "button_images" of containers (images) for some different buttons. There are 7 repetitions for the 7 buttons.

I have a global number field "selected_button_num" in design_elements that holds the current button number (1-7). I have a global calc "button_shown" in design_elements that grabs the particular button image from the repeating container field based on the value in "selected_button_num".

Now, by changing the "selected_button_num" via a set script step, I can change the button graphic. I am doing this from a layout set to a different table. That table is related to the design_elements table.

The problem I have is that when the script runs while I'm on that layout, the "selected_button_num" changes, but the calc never occurs. I can work around this problem by changing to a layout attached to "design_elements", doing the set script step, then changing back to "original layout". I don't like this because of all the layout changing (slowing the system).

I guess my question boils down to: When does FileMaker 8 actually update a Calculation type field? Is there any way to force this to occur other than flipping to a layout that is connected to the table the Calculation field lives in?

Sorry if the way I wrote this up is confusing. Many thanks for any suggestions.

[Kent Searight]

I don't know the answer to your question concerning where a calculation update occurs in FM's sequence but my suggestion regarding forcing the calc is to commit the record via script after setting the "selected_button_num" field.

[mk500]

I don't know the answer to your question concerning where a calculation update occurs in FM's sequence but my suggestion regarding forcing the calc is to commit the record via script after setting the "selected_button_num" field.

Thanks for responding Kent_S. I tried putting in a "Commit Records/Requests" right after the "Set Field" step. It doesn't force the calc. I think the problem is that the context of my script is the layout I'm on, which is connected to "people" table, not "design_elements" table. So a "Commit Records/Requests" commits the current "people" record, not the "design_elements" record (which is where the value was set).

There doesn't seem to be a way to set the context of a script, it just takes from whatever layout you are on, is that right? And the commit step has no way of specifying context. So basically, changing layouts before setting values, then changing layouts back is the only way to get the calc to happen in that remote table.

This seems clunky, and it slows the GUI. I'll try using a Freeze Window at the beginning of the script to help this.

Thanks again for responding, and let me know if there are better ways for me to explain my problem, as I'm new to the forums.

[LaRetta]

" then changing layouts back is the only way to get the calc to happen in that remote table."

Have you tried Refresh Window and click Flush Cache? I don't have it in my version but supposedly it assists with refreshing when related values are involved.

[mk500]

I created an example file to show the problem.

In the example file: if you click buttons 1-5, you see the issue. "g_current_selected_repitition" changes appropriately, but "gc_repeating_based_on_current_selected" (the calc) does not. Button 6 runs my modified script which jumps to the other layout, does the set, then jumps back (this works, but this results in a LOT of layout changes in my solution, and seems like the wrong way to do it). Button 7 does adds a "Refresh Window [Flush cached join results]" step, but doesn't work.

I'm stumped.

When_Calc_Test.fp7.zip

[-Queue-]

See my response on FM Cafe.

[mk500]

See my response on FM Cafe.

By making the calculations unstored non-globals, the problem is fixed. Unfortunately, my solution relies on these fields being globals (as I don't want the data shared across multiple users).

But, at least we know the solution. Thanks!

[SlimJim]

If you need to have globals then try the following: this is a modification of your file from FMCafe.

When_Calc_Test.zip

[-Queue-]

Since the unstored calculation is based on a global, the data should already be independent for each user. There should be no need to make it global as well (unless I am missing something).

[mk500]

Thanks slim! That's a great solution. Thanks for taking the time to make the example.