User Defined Functions NOT recalculating

后端 未结 11 2040
渐次进展
渐次进展 2020-12-15 20:27

I recently took a large, stable XLSM file, and split it apart into an XLAM and XLSX. Thousands of cells in the XLSX call (udfs) functions in the XLAM, and each such udf beg

相关标签:
11条回答
  • 2020-12-15 21:12

    Ice ages after the original question, but ran into a similar problem just today where I had created a UDF to determine which values of a pivot table filter were selected. The UDF would work fine in when running in macro editor as well as when directly updating the field where the UDF was used, but would throw a "#VALUE!" when updating the sheet or pivot table.

    It was killing me until I incrementally added content from my original UDF to Ali's simple monitorRange function. I then found that my UDF had a pivot table refresh statement that when removed eliminated the "#VALUE!" error. Below is the specific offending lines from my UDF, but I the general rule is that the UDF cannot have any code in its call chain that updates other workbook content. That is, the UDF must only GET values, NOT SET values.

    I verified this with the following two scenarios, which both cause this error:

    1. Refresh a pivot, e.g.: pt.PivotCache.Refresh
    2. Change a value of another cell, e.g.: Range("AA1").Value = "Test"

    Strangely, I tested and found that it is absolutely okay (kinda cool, actually) that the UDF can include a MsgBox call to display a dialog without problem. This would allow a UDF to monitor a range, then popup a msgbox dialog for any condition you wish to include in the UDF. I will keep that in mind for other situations.

    Hope this helps others running afoul of this nasty litter issue.

    0 讨论(0)
  • 2020-12-15 21:19

    Here is what I found. I haven't tested it but I believe there may be a work-around.

    This is a direct quote: "Excel depends on analysis of the input arguments of a Function to determine when a Function needs to be evaluated by a recalculation. "

    from http://www.decisionmodels.com/calcsecretsj.htm

    Here's what I'm going to try later today. I am going to generate a specific address of a table, dynamically within my function. Based on why we're here, I should not get an update should the value at the calculated address change.

    By including the whole table as a parameter, even without using the parameter, the function should update if anything in the table changes.

    In this way, your function hits the dependency tree regardless if you actually process the whole table.

    0 讨论(0)
  • 2020-12-15 21:20

    Figured it out - not sure why Microsoft has this "feature":

    The condition arises when a virgin XLSX that uses an XLAM function is opened / created prior to opening the XLAM. In this case no amount of cajoling will cause the XLSX formulas to bind to and execute those XLAM functions, UNLESS you go into each cell & touch the formula bar & hit ENTER (or, as I discovered, do so en masse via a global replace - in my case all the funcs began w a "k", so globally replacing "k" with "k" fixed the error). The problem does not occur if the XLAM is opened first.

    0 讨论(0)
  • 2020-12-15 21:20

    One possible solution: Set calculation mode to manual, then back to automatic

        Application.Calculation = xlCalculationManual
        Application.Calculation = xlCalculationAutomatic
    
    0 讨论(0)
  • 2020-12-15 21:21

    This works:

    Sub Force_Recalc()
        Cells.Replace What:="=", Replacement:="=", LookAt:=xlPart, SearchOrder _
            :=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
    End Sub
    
    0 讨论(0)
提交回复
热议问题