Conditional formatting cannot change the value of a field so there is no way to use a conditional format expression to compute the total and assign it to a field without help. A conditional format calculation can assign a value to a variable as a "side effect" of the conditional formatting expression evaluating, but you'd still need to then use a script to copy the value into your field and you'd need that script to perform every time something in your data changes such that the value needs recalculating. (This is why fields that compute totals of values from a related field are unstored--to ensure that the totals they display are properly up to date.)
Conditional format expressions, by the way, evaluate even more frequently than unstored calculations. Those that refer to aggregate functions like sum or a summary type field can, in fact, be a reason that a layout becomes slow to update properly once the records being "summed" become a large set of records.
OK, thanks Phil. So, in your opinion should I just stick with the unstored calculation? I watched the Shaking the Dependency Tree video that you recommended (it was very good by the way) and that's what got me started on thinking about using Conditional Formatting for this Sum, but I guess I was confused.
If you don't experience any issues with using the unstored calculation, use it.
There are ways to replace such an field with a simple number field using a transactional process where any data changes that modify a value result in a script being performed to recalculate the total and set the number field to the new total, but this is not a process to enter lightly as you'd have to identify every user interaction: changing a record, adding a new record, deleting a record... that might require the update and then you'd need to put script triggers or buttons in place that perform the needed update script.
OK, thank you very much.