This removes the POILogger and POILogFactory mechanism for logging. This mechanism was created at a time when the Java landscape looked very different than it does today.
Log4j 2 is an Apache Foundation project that is well maintained and is widely regarded as having good performance and capabilities. We use only the Log4j API artifact. This lets application developers choose how they want to capture logging events if at all. Integrations with Log4j 2 Core and Logback are available from the Log4j project.
Closes #224
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1886770 13f79535-47bb-0310-9956-ffa450edef68
#63264 Conditional Format rule evaluation calculates relative references incorrectly
Fixing the offset calculation and passing the top-left-most region rather than the region matching the current cell fixed these cases. I've augmented unit tests to check for them to avoid future regressions.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1855619 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
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 getters for setIgnoreMissingWorkbooks and setDebugEvaluationOutputForNextEval; add internal decorator; getSupportedFunctionNames and getNotSupportedFunctionNames should return unmodifiable collections
bug 57840: add javadocs (warn about stale XSSFTable cache), remove rowIndex argument from calls to FormulaParser.parse(String, FormulaParsingWorkbook, FormulaType, int sheetIndex) when rowIndex is irrelevant, clear xmlColumnPr and commonXPath during updateHeaders so that users have a mechanism to clear invalidated cached values
Start to update how the formula parser looks up sheets from formula ptgs, to account for the differences in how HSSF and XSSF store references to external sheets. For #56737
The way that HSSF and XSSF stores references to external sheets are rather different, so begin to reflect that in how we parse their formulas into Ptgs
Have WorkbookEvaluator process NameXPtgs, rather than returning a NameXEval which later places didn't handle. Largely allows us to process the .xls version of the test file for #56737 (but filenames aren't quite the same as in Excel)