Try using a calculated field = to the summary field but use Textstyleadd and Textcolor functions to format based on your conditionals.
Btw I have found Conditional formatting works fine for list or table values in 12 if you done over do it - although I have not aplied it to summary fields though. Possibly your condition calc is the issue?
What is the calcuation used in the formatting condition?
Try using somthing very simple like "Self>2" as a test. If that is not slow, then the issue is your formula, not CF per se.
Yes, I agree the answer is probably in a complex conditional formatting formula. I want the field to have a fill color calculated on a range of colors from light to dark in 8 increments. In FMP 11 it works in couple of seconds cascading through the formulae below, without the formulae (and just the results of the summary fields) it works in a couple of seconds in FMP 12. With the formulae in FMP 12 it is 18 seconds, which is just too long. I do not know how to make the formulae more efficient, but I suspect if that is possible, it would speed up the formatting. Here it is:
Formula is Self ≥ 0 and Self ≤ Weighted_ltem_1 --> Text Color, Fill Color
Formula is Self > (Weighted_ltem_1) and Self ≤ (Weighted_ltem_2) --> Text Color, Fill Color
Formula is Self > (Weighted_ltem_2) and Self ≤ (Weighted_ltem_3) --> Text Color, Fill Color
Formula is Self > (Weighted_ltem_3) and Self ≤ (Weighted_ltem_4) --> Fill Color
Formula is Self > (Weighted_ltem_4) and Self ≤ (Weighted_ltem_5) --> Fill Color
Formula is Self > (Weighted_ltem_5) and Self ≤ (Weighted_ltem_6) --> Fill Color
Formula is Self > (Weighted_ltem_6) and Self ≤ (Weighted_ltem_7) --> Fill Color
Formula is Self > (Weighted_ltem_7) and Self ≤ (Weighted_ltem_8) --> Fill Color
I have a few questions for you, should you be willing to indulge my curiosity.
Once the user is on the slow list layout, are they performing actions which would require that the summaries be recalculated, i.e. they are peforming actions which change data or change the found set?
- or -
Is the slow list layout simply for scrolling through and viewing a set of records and then perhaps navigating somewhere else, such as a detail view of an individual record?
Are any of the Weighted_Item_N references calculated and, if so, are those calculations also high-overhead?
Is this a multi-user solution?
1 of 1 people found this helpful
This is a cascading calculation and the way it works you really only need to test the < value for each level as passing the previous level means we know its > the previous level.
For example if Self is less the Weighted_ltem_1 you don't need to check for it being greater than 0.
If Self passes the first test - because it is greater then Weighted_ltem_1 - then it does not need to be checked at the next level.
Self < Weighted_ltem_2 is sufficient since we know it is > Weighted_ltem_1 or it would have already been processed.
The > or < processing requires knowing if its Top-to-Bottom or Bottom-to-Top. In this case the last matching condition is the one used. So you need to match from Bottom-to-Top so that the greatest is tested first and the least is tested last.
Self > Weighted_ltem_8 //If it passes this one we know it won't pass any of the others/
Self < Weighted_ltem_8 //If it passes this one it may still pass a later one. Only of the later ones do not pass is this the 'last one'
Self < Weighted_ltem_7
Self < Weighted_ltem_6
Self < Weighted_ltem_5
Self < Weighted_ltem_4
Self < Weighted_ltem_3
Self < Weighted_ltem_2
Self < Weighted_ltem_1
Self < 0 //You didn't add this condition so it may not be possible of the value to be negative.?
For example if the value is between Weighted_ltem_3 and Weighted_ltem_4 then it will pass 8, 7, 6, 5, 4 but fail on 3, 2, 1, 0. So the last one' passed is Weighted_ltem_4.
The slow layout is sufficiently small that it fits into one screen so there is no recalculation. Yes, Weighted_Item_N references are calculated, but display within about two seconds.
Thank you for this advice. In retrospect it is the obvious way to handle cascading calculations, but I did not think it through well enough. Ordering the calculations by Bottom-to-Top increased the speed of the display of the conditional formatting from the original 18 seconds to 13 seconds -- noticeably faster. Thanks.
What REALLY helped is updating to FMP 12.0 v3. Just using the new FMP decreased the time to a manageable 3.4 seconds.