https://bugs.documentfoundation.org/show_bug.cgi?id=164732
--- Comment #10 from Alfio <[email protected]> --- (In reply to Laurent Redor from comment #8) > We can consider it as an enhancement request as it is a performance problem. > But since I couldn't figure out the logic between my different example > cases, I consider it a bug instead. I reproduced it on version 25.2.3.2. I also did more extensive testing, editing the attached files, so now I can add new informations. I found out that your condition "when there are at least the same macro twice one below the other" is not exact. More precisely, the recalculation occurs when two cells, one below the other, contains the same *expression* calling your macros. The expression =MYMACRO1($B$2:$B$4)+0 is not same as =MYMACRO1($B$2:$B$4), you can use it as another workaround. My tests demonstrate that recalculation *has* a deterministic reason: the argument that you used calling your macros. Indeed, the range $B$2:$B$4 belongs to the table you are filtering. When filtering, if the filter hides/reveals some cells belonging to $B$2:$B$4, the expression is recalculated, else is not recalculated. The fpy's link, about OpenFormula standard, brings me to suppose that Calc normally checks, after each filtering, if a recalculation is needed: when a formula contains references to cells that are changing their visibility status, the expression is recalculated. This "filter dependency" is not expressly mentioned in the "3.5 When recalculation occurs" section of the standard. But it is explainable, because the cell's visibility can change the result of a function, as happens with SUBTOTAL(). Therefore IMHO filter recalculation is normal. On the contrary, I expected it happens more frequently, not only when an expression is written twice on consecutive cells of the same column. But that would be another story. -- You are receiving this mail because: You are the assignee for the bug.
