Detecting Errors in Conditional Formatting Formulas

Like many, I've been frustrated when my carefully crafted conditional formatting becomes bifurcated after innocently performing a copy/paste or some other such sin. And Excel's miserable Conditional Formatting Rules Manager makes it a chore to fix the mangled rules. So I've written macros to backup and restore the active sheet's conditional formatting (CF) using named ranges that auto-adjust to row/column changes. You can download my M_CFBackup.bas module (text) file from Google Drive here:
https://drive.google.com/open?id=171GNuD7LSFpPz9ep-oF0gB-aY_MUgakv

First make sure the current CF is correct by use of the Conditional Formatting Rules Manager (Alt+H+L+R), then use CFBackup. If you later find the CF has become corrupted, using CFRestore will usually fix the problem. I have tested CFBackup and CFRestore with many scenarios, but not all. If you discover any issues, please add a comment to this thread.

@David Gray:

Sure, we all do that, unless applying the simplest of things or something ad hoc that won't survive closing the spreadsheet.

The problem addressed in this tip is that the circumstances of the formatting formulas change over time, sometimes in ways that matter. And that Excel does not offer any built-in way to notice those times, that nothing draws attention to them, that no error messages are passed to US.

Which is NOT addressed by the work process followed setting up the rules, unless one can anticipate a particular failure in a given case and work out a way around it before it ever happens.

What we really need is someone to put some "real" effort into a commercial Add-In that reliably notices them. Perhaps sell it directly for $10, or sell it to someone like Ku--Tools or AbleBits for inclusion in their products.

It would seriously behoove MS to improve this. The validity of spreadsheet models, even the possibility of their validity being demonstrated, for non-simple products that companies commit mega-ducats based upon, is a SERIOUS question in business today. My take on spreadsheets, if one has programming available in-house, or services routinely available out-of-house, is one wants to "spreadsheet" as a product maturing process, then turn it over to programmers to write a dedicated program for. One that CAN be verified to do what it claims. Of course, who does that? But as the yeers pass and the available programming labor continues to pile up as more and more people enter the field, that kind of thing could replace "serious" spreadsheets. Then Excel's market would become a rather declining market, maybe, as, if the development of the tool would not be permanently in spreadsheet hands, other, free, spreadsheets could be used. Only has to work a year perhaps? Who cares if it's a Google spreadsheet then? It doesn't need slickness, just to provide the functionality and once that's road-tested, it'll be replaced with a proper program/app. Even MS is pushing that with their PowerApps. Maybe that's why they don't fix primitive services like Conditional Formatting. Huh...

When I am concerned that a formula upon which I intend to base a conditional format might raise errors, I have a two-step process, applied at design time, that has served me well for over a decade.

First, I code the formula in a regular cell, and thoroughly test it by supplying a variety of problematic inputs. This is easier than you think, since live cells that affect a formula can be temporarily changed, one at a time, and restored by way of the Ctrl-Z (undo) accelerator.

Second, once I have the conditional format set up, I apply the same technique, changing inputs to force the formula to evaluate to TRUE, and verifying that the color changes as expected.

If you are a software engineer, there is a name for this technique, unit testing. Though not as formal as the approaches applied in traditional software engineering, such informal unit testing is effective, and I use it regularly to test complex formulas.

PROBLEM:
For Each fc In c.FormatConditions
If InStr(1, fc.Formula1, "#REF!", _
vbBinaryCompare) > 0 Then ...

failed with:
Run-time error 438: "Object doesn't support this property or method"

VBA debug quicklook shows the following:
Expression | Value | Type
--------+---------+----------------------------
c | "DOW" | Variant/Object/Range
fc | | Variant/Object/UniqueValues

(fc is empty / nothing)

VBA debug quicklook for "fc.Formula1" shows same error as above

The c Value was "DOW" - which I found in cell A1 (and ONLY in Cell A1 in in the whole workbook)
Cell $A$1 had a "Duplicate Values" conditional formula for a range of cell $A$1 ONLY! (And which I never entered, and have no idea where it came from!)
After deleting the Conditiona Format from $A$1, the Macro ran...
I added a "Duplicate Values" fc back to cell $A$1, and got the same error.

I have seen this with 'For Each' loops before - you can hit a type of Variant that does NOT have the property (.Formula1) and blows up the VBA. I had to put special checks in the code to catch this problem.

The variable fc has not been declared.