Firstly, I am now puzzled as to how to rationalise this with the allegation in the documentation that "You can also use aggreations in related forms as the foundset will be set automatically to the relation"
You can aggregate on one parentrecord to many childRecords.
NOT on a foundset of parentrecords to all their childrecords.
Also, the calculation "sum(relation:fieldname)" may not be provided - but Servoy gives the appearance of providing it (or more correctly of providing "relation.sum(fieldname)".
Yes, Servoy does provide this as explained.
There is, I concede, some scope for ambiguity in such a construct but the placement of this in the Trailing Grand Summary should either (a) trigger a warning/error or (b) clarify the potential ambiguity and sum over all the related records.
In list views, just use footers/headers. Aggregates don't need to be in TGSummaries.
Regarding the objection that the desired functionality would be computationally expensive: OK, that is, IMHO, good reason for a warning but not to omit what is arguably basic functionality. The fact that an operation is computationally expensive may, IMHO, be construed as a very good argument for implementing it - where the computational expense derives from the nature of the underlying question then getting a computer to labour over the matter may well be the most practical solution (I'm not volunteering to substitute myself for the computer in these matters!).
This functionality isn't omitted, as example showed.
Lastly, in matters which are computationally expensive, I much prefer correct answers to either immediate answers or to misleading answers.
Aren't you lucky getting immediate AND correct anwsers twice?
So bottomline, as a rule of thumb:
1)Use aggregates in headers and footers. Use Trailing grand summaries for subsummary reports in preview mode.
2)If there's a related column in your list, that aggregates on childrecords,
create a stored calc (see example) and aggregate on it.
Thanks.