Current implementation for all methods that take a single cell reference argument:
- `setCellValue()`
- `setCellValueExplicit()`
- `getCell()`
- `cellExists()`
- `setBreak()`
- `freezePane()`
- `getComment()`
Also introducing a CellRange object to work with similar cases for methods that accept a cell range rather than simply a cell address; and RowRange/ColumnRange objects for those cases.
Still need to apply to methods that accept a cell range or single cell:
- `mergeCells()`
- `unmergeCells()`
- `protectCells()`
- `unprotectCells()`
- `setAutoFilter()`
Then there's a few special cases that accept row and column ranges, not simply cell ranges; or a series of cell ranges.
The code could stil do with some cleaning up, and better optimisation for memory usage; but all tests are passing... that's for full multi-level sorting (including direction), and allowing for correct sorting of sting/numeric datatypes.
Despite typehint, Scrutinizer assigns union type to a variable, resulting in subsequent faulty analysis of a method call invoked on that variable. Adding a bogus routine that will never actually be called to one module eliminates 8 Scrutinizer errors.
* Eliminate Most Scrutinizer Problems in Test Suite
Mostly minor code changes, with some annotations.
* Missed 2 php-cs-fixer Problems
They should be fixed now.
Initial work implementing the FILTER() Lookup/Reference function
Tighten up on vector formats; and provide a couple of helper methods for testing row/column vectors
Xls Reader: initial work on reading conditional formatting
Currently the ranges and CF Rules are read, but only the most basic style information for the font (size, weight and colour)
This will be expanded with future PRs
- Update existing ranges, expanding if necessary, rather than trying to clone for each individual cell
- Update conditions, so that cell references and formulae are maintained correctly
Note that absolute as well as relative cell references should be updated in conditions
* Add editAs Property for 2-cell Anchor Drawings
This change builds on PR #2532 (@naotake51 as PR #2532), using ideas from PR #2237 (@AdamGaskins), which has had changes requested for several months. It covers a lot of the same ground as 2532. In Excel, two-cell anchor drawings can be edited as "twocell", "onecell", or "absolute". This PR adds support for those options, with a sample file that demonstrates the difference in addition to unit tests. Several other tests are added to improve the spotty coverage for Drawings.
There have been several other tickets referencing two cell anchors, including issue #1159 and PR #1160 (@sgarwood, who also added support for editAs), PR #643, and issue #126, all now closed but not necessarily entirely resolved. I will try to ensure that those tickets are addressed with this one.
And, in trying to make sure 1160 is covered, I stumbled upon a bug. If you use the same image resource to create two+ memory drawings, the MemoryDrawing destructor for the first will cause the rest to generate a very long warning message. This is not a problem for Php8+, only for Php7-. I have suppressed the message in the MemoryDrawing constructor. 1160 went stale due to an unresolved test error, but I don't think this was the problem. At any rate, its test works now.
* Scrutinizer
It reported 1 minor issue (fixed normally), and 2 major. One is fixed with a kludge. The other is a case where Scrutinizer's analysis is just wrong, and I can't figure out a kludge. But I was able to add an annotation (the first time I've managed to get one past phpcs/php-cs-fixer). We'll see.
Jpgraph does not use namespaces. Neither do the Samples members of this project. As a result, Scrutinizer complains about 13 cases of `use PhpOffice\PhpSpreadsheet\Chart\Legend;`, since this theoretically could cause the use of two different Legend classes in the empty namespace. It suggests using a class alias for Legend, which this PR does in every applicable case. It is a regrettable problem, but it is easy to fix.
For a recent change, I removed some errors from Phpstan baseline and instead added annotations in the source members. I did this work incrementally, and was surprised when php-cs-fixer required a change from `// @phpstan-ignore-next-line` to `/** @phpstan-ignore-next-line */`. No problem thinks I, and continue to modify several members using the new convention until php-cs-fixer required a change from `/** @phpstan-ignore-next-line */` to `// @phpstan-ignore-next-line`??? I did as directed, and continued to be surprised for the rest of that ticket.
Having had time to research, the problem is due to two options in the php-cs-fixer config file `'comment_to_phpdoc' => true` and `'phpdoc_to_comment' => true`. It seems that php-cs-fixer is treating these annotations the same as doc-blocks, expecting `/**` before a `structural element`, and `//` otherwise. For the statements where I had questions, it expects `/**` before a statement which you might be able to precede with `/** @var`, and `//` where you would not be able to precede it with `/** @var`. However, in this case, what it is doing is forcing what appear to be inconsistencies between otherwise identical statements, whereas php-cs-fixer is supposed to be supporting consistent syntax throughout the project. This PR changes both options to false, allowing (but not requiring) a consistent syntax for these examples. It contains an example of a change from each format to the other, changes which php-cs-fixer would previously have flagged.
An added bonus for this change is that Scrutinizer annotations can now be added to the code; these were often rejected by php-cs-fixer. These should, of course, be used very conservatively, but there are cases where Scrutinizer's analysis is either faulty or not helpful. This PR takes advantage of the change by adding annotations to eliminate the two existing problems which Scrutinizer classifies as 'Security', problems for which there is no sensible way to satisfy Scrutinizer's complaint.
No executable code is changed by this PR.
MarkBaker
Mark Baker
oleibman