Since upgrading to V10 I have noticed a few odd occurrences when using "insert calculated resulted" script step. It seems to place the data in the wrong field. It had all been working fine in 9 but since the upgrade it has been problematic.

It doesn't happen all the time, it seems to vary from script to script and some can be solved by running the step while in a different layout and switching back. All very odd.

Any ideas?

Thanks

Rufus

I have to say, I've never used Insert Calc Result. I'd look for a context issue (if switching layouts helps, perhaps you're actually switching to the correct context).

Why not change to Set Field?

Beyond that we now are allowed indirection with fm10, is Set Field[ dangerous in a similar way, if you avoid writing a fields name in the reciever part. Then will it follow the flow or tab-order in the layout.

But everything based on the order in the layout are bound to give errors if something suddenly changes position. I too haver never really used Insert Calculated result ... it must be kept there as legacy compatibility from fm6 where it had it's use when writing a date-range in date field to circumvent the bleeping when "..." was attempted, via Set Field[

But at this day and age has it no use anymore, except in either poorly designed solutions or migrated solutions from pre fm7 ... where it then eagerly awaits being turned to Set Field[

--sd

I find it very useful in script-assisted editing, for example inserting boiler-plate text at cursor position.

I find insert calculated result is a very useful script step and I've never seen it fail before.

I can't see that this can be context or position related as the script step specifies the field to insert the data into. It's just that for some reason, it sometimes gets it wrong.

Further to this, i've just noticed that it has started happening ( on occasion ) in V9 as well. Could the database have become corrupted? If that is the case, how would I fixed. Clone and re-populate?

Thanks

Check the tab-order, perhaps it's where weakest spot is in the scenario.

If a field is deleted and then added again later, could it explain the entire issue. "Insert" "copy" and "Paste" strong dependency on a specific layout is pretty risky in my opinion - it's much more my liking to make wrappers, such as:

http://web.mac.com/zueiv/iWeb/FileMaker/Script%20Killing%20Techniques/AFA363C6-2D85-4C6D-82E2-273F3722A69E.html

Because a uniform method exists for the entire solution universally.

--sd

Hey, Rufus.

I'll bet money that you've got a conditional 'Go To Layout' script step hidden away in there somewhere.

I'll bet money that you've got a conditional 'Go To Layout' script step hidden away in there somewhere.

Plausible indeed! Lets get a dump of the script where it occurs.

--sd

Well, yes it specifies the field, but are you choosing from a related TO?

Hello,

I have the same problem Rufus mentioned.

This script below doesn't do what it's expected to do. It tries to insert the value of the variable into a different (incorrect) field (which FYI is from a different related TO). I can't see any logic as to why that field is chosen. When I deleted the incorrect field, then another incorrect field was chosen. When I deleted THAT field, then everything worked properly.

This used to work in FM 9. I recently switched from FM 9 to FM 10 (both for client and server, though not at the same time.) If I now open the file directly in FM9 (i.e., not served/shared), it still has the problem.

# Go to Layout [ “Main” (END__) ]

# Set Variable [ $EndowmentKey; Value:Get( ScriptParameter ) ]

# If [ IsEmpty ( $EndowmentKey ) ]

# Else

# Enter Find Mode [ ]

# Insert Calculated Result [ END__:e_endowment_pk; $EndowmentKey ] [ Select ]

# Perform Find [ ]

# End If

Thanks,

Marek

This works now.

I replaced the script step "Insert Calculated Result" with "Set Field" (as suggested by bcooney, 01/09/09 07:36 AM)

I had been under the impression that "Set Field" didn't work with calculations (more specifically with variables). Maybe it didn't use calculations in earlier versions, or maybe my impression was wrong.

Marek