Hi folks, I use an event-based script trigger to populate the next portal row with looked up or calculated data when data for a field on the previous portal row gets edited, provided that one first clicks outside the portal. But clicking outside of the portal to trigger a script isn't much easier than clicking a button to trigger the script. It would be nice to be able to tab out of the edited field (an action that now tabs me into the next portal row, which stays blank) and have the tabbing trigger population of the next portal row.

Is this possible?

Can't the script remember the portal row and current field, commit the record, then return to the portal row and field?

Hi, I think my script ("test committing script") incorporates your suggestion, but still requires clicking outside the portal rather than tabbing out. Here is the script:

If [group payments::Excess Amount > 0]

Go to Portal Row [select; Last]

Go to Portal Row [select; Next]

Set Field [payments for individuals::amount for individual; group payments::Excess Amount]

Commit Records/Requests []

End If

More details. The parent table is "group payments" and the child table is "payments for individuals." group payments::Excess Amount is a calculation field that incorporates the script trigger, where

group payments::Excess Amount =

group payment amount - Sum ( payments for individuals::amount for individual )

&

If (payment amount - Sum ( payments for individuals::amount for individual ) ≠ 0 ; XMpl_StartScript( Get(FileName) ; "Test Committing Script" ) )

When I see questions like this, does it make me wonder why concepts like:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000333

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000334

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000061

...have been ignored???

--sd

Thanks for the response, Soren, which helps to clarify the motivating issue.

I'm guessing Soren's question is why I use a Set Field script step rather than a Lookup to enter data into a field in the portal row, since Soren's examples all involve using Lookups to get portal row field data from previous portal rows.

The answer is that in these examples (and in my example back when I tried using only Lookups rather than a script), new populated portal rows don't get created automatically. You have to enter data into at least one field in a portal row and then commit the record to activate the lookups, it seems. The Set Field script step is merely providing this activation. I want automatic creation and population of portal row records so that the unallocated portion of a group payment automatically gets assigned to an individual in a portal row, where that individual is selected based on looked up/calculated data as in Soren's examples.