The portal method works because the active record and layout are in the parent table, so the record updates. The list view method means the parent data is not automatically updated unless you refresh the layout somehow—that is what you are doing when you manually switch records; the parent data refreshes when you return. What you need to do is create a script which achieves that purpose and then run it, say, by way of a script trigger on exiting the relevant child field in your list layout.
Thanks, @keywords. This seems clear, but requires that each and every changable field in the record cause that script to run, right?
So that causes 2 more questions:
Is there a record update event that would suffice, so I only need to do one trigger?
Can you suggest script steps to use so it will update the "parent" record?
In the attached file the SUM field updates without the need for a script, but your file may contain a more complex calc that is not updating readily. Nevertheless a simple script such as the one included should do the job.
ParentUpdateDEMO.fmp12.zip 66.4 K
Thanks for the idea, but unfortunately this technique doesn't work for my layout. It is a bit more complex than yours, but not very much.
The parent field that was a calculated total of the hours of all the child records' hours fields was not enabled in browse mode. If I enable it, then after updating one of the detail hours fields, click in the total hours field, it does update properly. Unfortunately, when the trigger script tells it to do that same thing, the update doesn't happen.
Interestingly, if I have 2 child records, changing the first one works just fine. Everything updates without any script in place. If I change the second child record, I either have to activate the first one by clicking somewhere on that row, OR click inside the total hours field in the header section of my layout.
If I can't figure out why this doesn't work in a short time, I may need to re-architect the IPAD layout, and put a portal in there, similar to the DESKTOP layout.
Any other ideas? Thanks...
Re: "The parent field that was a calculated total of the hours of all the child records' hours fields was not enabled in browse mode" I presume by this you mean that you have switched off field entry in the Inspector. While that setting will prevent manual entry into the field, entry via a script is not affected.
Re: "If I enable it, then after updating one of the detail hours fields, click in the total hours field, it does update properly." If this process works manually to update the field contents, then it should also work via a script. Make sure you have Select/perform checked on that script step.
That aside, it sounds like you may have either a more complex calculation or more complex relationship involved. Without seeing the file it's hard to offer much more.
You are correct, but it was disabled out of the box. Remember I said it was from the time billing starter solution. In either case, the script just doesn't do what it does in your solution. I didn't try single stepping through it (I have advanced), so may try that.
This baffles me also. I can edit the detail record, then simply click inside of the total hours field up in the header (after enabling in browse mode), and immediately the total is updated. It just doesn't happen when I use the script steps. I did have Select/perform checked.
The starter solution has a time in, time out and hours (calculated) in the detail table, and the grand total field takes the sum of that hours detail field. The only thing I did was to add 3 more sets of in, out, hours and a grand total hours field to the detail table. This is because it is to be used as a timesheet entry program, and a typical day can have 4 time segments (with lunch and breaks). So now the total hours in the header section takes the sum of the grand total hours field of the detail table. I know the calculations are working, because if I make the edits in the first record, it automatically updates the header total. If I make the edits in the second record, I must either manually click in the grand total header field on the layout, OR simply change focus from the second to the first detail record in order for the header total to update.
Still don't understand why the updating happens properly on the first detail record, but not on the second. This is quite confusing. In the meantime, I have copied the layout and in the new version based on the header table instead, changed it to a portal. Everything works great using that method.
Thanks anyway for trying to help.
OK, I've just taken a look at the Time Billing Starter Solution and can see the problem. When you add a new detail record in the portal on the desktop version of the Time Billing Details layout the detail record is being added via the relationship, and hence the join data is automatically being added to the TIME BILLING ID MATCH FIELD, so that the record is straightaway related to the parent record. On the other hand, the Add Line Item button on the list layout merely adds a new record; there is no means of linking the new detail record to the parent. That is why only changes to the first record trigger an update to the total—the second and subsequent fields are not automatically related to the parent.
The starter solution attempts to address entering the match data by autoentering this data from a global variable, but if you haven't clicked the necessary buttons to set up the global variable then it doesn't work. I suggest you create a more robust and dependable approach than that.
Since you have FMAdvanced it would be worth your while spending some time stepping through the built in scripts to better understand what is happening, and which scripts to modify.
Thanks for taking the time to research this. I assumed that a starter solution would work properly. I appreciate the insight. I have already changed the layout to use a portal, which solves the issue. It's surprising that the starter solution would use different methods on desktop and ipad layouts.
"I assumed that a starter solution would work properly"
So did I when FM first started providing them. I don't know what ground rules FM sets for its starter solutions, but they all seem to me to include a lot of "quick and dirty" stuff.
As to why they iPad layout method is different from the desktop layout method, there may be good reason for that. I haven't done a lot of FMGo work yet, but perhaps portals don't work as well on an iPad; if that is the case, however, I'd have expected something better than a single-step button that relies on a global variable having been set by some other process, since the layout clearly assumes each record created should be related to a parent.
You are so right. That layout turned out to be a bit Mickey-Mouse.
Changing to a portal worked much better. I've been using portals in IOS layouts, and they work as expected. If the layout is based on one of the "Touch" themes, the portal is automatically created with an appropriate row size.