Implement DMAX and DSUM functions, following the pattern from DMIN.
Refactored the D* function enum to have instances return the function implementation instances rather than using a case construct, now that Java 8 is required.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1819376 13f79535-47bb-0310-9956-ffa450edef68
Bug #61841 - Unnecessary long computation when evaluating VLOOKUP on all column reference
Found some optimizations in the general evaluation framework related to blank cells in rows beyond the last defined row of a sheet.
I don't see any issue with passing a bit of context down deeper into this framework, as it's all POI-internal and only had one calling path.
See the above bug for the performance analysis. Not specifically related to VLOOKUP, but improves that case by more than 2/3 as well.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1817252 13f79535-47bb-0310-9956-ffa450edef68
Fixes Bug 61764 Conditional formatting rules don't evaluate properly for some multi-range rule definitions
Fixes Bug 61761 Conditional formatting rule evaluation doesn't like comparing cells of different types
fixed, with unit tests.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1815298 13f79535-47bb-0310-9956-ffa450edef68
Fix 60384 and 60709: When shifting with merged regions we should correctly check if the region is moved along or needs to be removed because it is not fully kept via the shifting. This was broken by the fix for bug 59740, now additional unit tests ensure that it works better.
now evaluating based on cell references instead, and watching out for undefined cells in rules that require a cell.
Added unit test based on previously failing file.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1805245 13f79535-47bb-0310-9956-ffa450edef68
One of my users found that my initial implementation was lacking a core distinction - most evaluations expect a single result, and "unwrap" 2/3D ValueEval results to a single value based on the input row/column.
However, data validation list formulas explicitly are expected to return a 2D ValueEval. This worked when the formula was simple and evaluated to a single Ptg, but only returned one value when the formula was more complex, or referenced a named range defined as a complex formula.
This change teaches WorkbookEvaluator about the distinction, by way of a new attribute for FormulaType.
There is room for discussion over how it is implemented, but this works for me.
Includes the failing workbook we had as a new unit test.
While I was in FormulaType I went ahead and removed the deprecated, unused, and redundant code marked for removal in 3.17.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1803121 13f79535-47bb-0310-9956-ffa450edef68
Add file that failed regression tests as a unit test.
Adjust table style processing to allow for AlternateContent wrappers for table element style definitions.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1799733 13f79535-47bb-0310-9956-ffa450edef68
XSSFTable should format numeric/date cells when used as Column Header names as Excel does, see https://stackoverflow.com/questions/44407111/apache-poi-cant-format-filled-cells-as-numeric
Bug 60898 - XSSFColor's getARGB() method returns a wrong color value when a workbook has a custom indexed color
teach XSSFColor and most things that create instances about indexed colors.
Null is a valid value for IndexedColorMap instances - the existing built-in default colors are used.
Whenever a workbook style is accessible in the call hierarchy its color mappings are passed down now.
Thanks for the unit test in the issue, it now passes.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1796359 13f79535-47bb-0310-9956-ffa450edef68
Tim Allison
Dominik Stadler
Yegor Kozlov
Greg Woolsey
Andreas Beeker
Alain Béarez
Javen O'Neal
PJ Fanning
Nick Burch