Ok, now it looks like we may have to backtrack even further. What we need to
know are the sheet names and cell addresses where a user actually types
information into a cell that is used by any of the cells leading up to a
change in V17 and X25. Those are going to be cells without a formula in
them, but that are referenced in one of the formulas you've provided here.
For example, you show cell X25 as having formula =U25/25, with U25 also
holding a formula (= U29/U4), and both U29 and U4 have formulas that SUM()
ranges. Perhaps you are typing entries into cells in the P2
2500 or D2
2500
ranges?
I begin to see why you had the original code attached to the _Calculate(),
and we may return to that, but it would be much better if we could just test
for a change in a cell/cells where you type in data that eventually affects
the results in V17 and X25. Then we could use the worksheet's _Change()
event rather effectively. The problem with this is that the _Change() event
does not fire when the change is because of the result of a formula
recalculating, only when a user types something into a cell (or deletes
something). So I think the optimum solution is to test for a change in a
cell that is typed into waaaaay back at the very beginning of the chain of
dependencies that lead to a result in V17/X25.
If that's not possible, then we may be able to deal with the Calculate()
event and approach it this way: after recalculating, test V17/X25 for a
change in value and if either has changed then copy that value to the other
location and "remember" the values of V17/X25 for the next time a calculation
is performed to see if they change then or not. The 'remembering' would be
done through a couple of Public (global) variables that would be initialized
during the Workbook_Open() event so we can detect changes later on.