Is =IF true/false conditions non-strict or strictly evaluated?

[johnzabroski_wam]

I am researching this, and unfortunately, Microsoft Excel documentation doesn't clearly explain this simple concept.  In programming language theory,

• IF is lazy/non-strictly evaluated if it doesn't evaluate value_if_true and value_if_false until it knows whether the logical_test is true or false.
• IF is strict if it does evaluate both value_if_true and value_if_false, regardless of whether the logical_test is true or false.

In my specific use case, I have a volatile true condition, and non-volatile or completely ignored false condition:

=IF(A2,VbaCallThatEncapsulatesVolatileCallToComAddin($H$5,D6,$D$5:$G$5,D6:G6),"")
=IF(A2,VbaCallThatEncapsulatesVolatileCallToComAddin($H$5,D6,$D$5:$G$5,D6:G6))

According to Excel documentation, the : operator has the highest precedence.  So, I would expect the ranges passed into my VbaCallThatEncapsulatesVolatileCallToComAddin to get evaluated first, but then it's less clear what gets evaluated next.

Here are the relevant documents I've read, neither of which answer my question:

https://support.office.com/en-us/article/calculation-operators-and-precedence-in-excel-48be406d-4975...

https://support.office.com/en-us/article/if-function-69aed7c9-4e8a-4755-a9bc-aa8bbff73be2

According to a thread on StackOverflow, no one is 100% sure, either.

https://stackoverflow.com/questions/10440104/does-excel-evaluate-both-result-arguments-supplied-to-t...

While people are able to show that there is no visible side effect for pure computations, it's less clear if Excel has simply suppressed the side effects and trapped #DIV/0! etc.  The third example demonstrates that if a formula contains a volatile function, Excel will ask you if you want to save your workbook when you close it.  It's not clear if Excel is doing this because the workbook contains any volatile function, or if because it thinks it has evaluated RAND().

[#2 · Accepted solution]

As far as I know, Excel does short-circuiting on IF and does not evaluate the "other part". You should be able to check that by logging which cells call your UDF (application.caller returns a pointer to that cell):

Public Function foobar()
    Debug.Print Application.Caller.Address
End Function

[#3]

@Jan Karel Pieterse Thanks for your helpful reply.

I was able to figure out that the issue was that my RtdServer was blocking the Excel UI thread, which caused unexpected behavior.  In addition, I discovered that in Excel 2007, Excel began supporting multi-threaded workbook calculations, and in Excel 2013, further enhanced multi-threaded workbook calculations with settings to disable on enable on a per-sheet basis these calculations.  I believe I had something like 84 cells calling my RtdServer via:

=IF(Some_Named_Cell, RTD("ProgId",,topic1,topic2,topic3,topic4)