You need to end your script (to increase the discount) with:
Refresh Window [ flush cached join results ]
In your script that modifies the value, include these steps after the change is made:
The alternative that does not require scripted support to keep the fields updated is to define calculation fields in your Invoice table that use the sum function to compute totals of your related items records. These usually update much more smoothly than summary field from the related table.
Phil said, "define calculation fields in your Invoice table that use the sum function to compute totals of your related items records. These usually update much more smoothly than summary field from the related table."
I agree, Phil, but people should also know its sinister side so I'll fill them in ... using Sum() is more resource-intensive and not nearly as flexible since defining a summary in a child table can be accessed from ANY related table whereas Sum() is limited to the table it is written in. I would rather refresh the few times it is required than to 'dog-down' the system every time I scroll through lists or otherwise use my records; less overall system stress particularly in larger record numbers.
It's definitely a case of balancing trade offs. The added "screen flash" from the window refresh is something I find especially irritating. I thus avoid using summary fields for this whenever possible, but fully agree with you that you have to keep an eye out for possible performance hits on some layouts--especially if you use a lot of these on a list/table view or the sum function accesses very large numbers of related values...
BTW, summary fields are also the best option when you use a filter expression with your portal as Sum functions will gypass the portal filter and a summary field located within the filtered portal does not...
Thank you guys so much!!!
I sort of like the idea, not having to put another summary field in the invoice table, since I really already have that same field in the items table.
On the other hand phil has brought some points here for the additional fields...so I guess I'll try both and see what works better for me:-D
Again, thanks so much!
But I know realize I can't put a summary field under the portal on the invoice layout and summarize the total of some field from the items table.
So I'd have to make it a calculation field, right?
Is that not way more effort for something, you'd expect to be really simple? What's the advantage of that?
"But I know realize I can't put a summary field under the portal on the invoice layout and summarize the total of some field from the items table."
Yes you can. If the portal is filtered, put a one-row portal just large enough for your summary total on the layout below the portal and filter it the same as your other portal. Put your summary field in that.
The fact that the summary field produces different results depending upon a filter makes it even more powerful ... you cannot filter a Sum() calculation.
I had the same issue: fields not refreshing on screen. Only after mouse click on object.
Refresh Windows didn't do the trick.
Commit Record didn't to the trick either.
Sop I solved it by giving the not-updating object a name (like: FinalAmountsDialogBox)
Then I added a script step: update object (with that name)
For me this worked.
This is an old Thread. Refresh Object did not exist at the time this question was originally asked.
I have also found that the SUM aggregate function in the parent table updates more smoothly for display purposes, but if you use the aggregation field in a calculation prior to committing the records, the underlying value does NOT equal what is displayed.
For example, if I use a portal to record debits and credits, but do not want to commit the records unless the debits equals the credits, using the SUM aggregate function fields does not work. I have tested this in version 14, but just upgraded to 15 so need to re-tested. In addition, I have only tested this in a client only (single user, no server) mode. Suggested solution to this problem have been been looping through the portal records through a script, and calculating the totals. I have also been directed to looking at ways to trigger the performance engine.
Curious to know if any one with detail "under the hood" FM knowledge could shed some light on this issue.