- 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.
Some work on refactoring the ReferenceHelper to extract the logic for updating cell references. This is a preliminary step toward allowing updates to absolute cell references, required to update Conditional Formatting rules.
And a bugfix when deleting cells that contain hyperlinks (the hperlinks weren't being deleted, so were being "inherited" by whatever cell moved to that address).
Plus some additional unit tests for the ReferenceHelper.
And a bugfix when deleting cells that contain hyperlinks (the hperlinks weren't being deleted, so were being "inherited" by whatever cell moved to that address)
The code is ugly as sin; but it works... I'll do some refactoring and cleaning later (once I've had some sleep, because I'm stupidly still working on this at 3am)
The main remaining issue is formulae that can't be parsed in BIFF8 files; e.g. formulae that use functions that aren't available. In this case, all CF in that worksheet is corrupted, and the file errors when opened, so it is a serious issue. The ISODD()/ISEVEN example in 07_Expression_Comparisons.php uses these, so I've temporarily commented out setting that CF range until I've solved that problem. There are other limitations listed in the BIFF documentation; but they're harder to detect.
I've also left a couple of debug statements in the code to display these formula errors: I'll remove them once I've resolved the issue.
BaseWriter openFileHandle opens its output file with mode `wb+`. We don't appear to attempt any reads on the file after it is opened in write mode, so `wb` should be sufficient. This may have been a factor in the need for PR #2326, and is likely to be responsible for issue #2372.
These changes have already been implemented twice, and been regressed twice. I'll try once more (with a different approach), then give up ...
As configured, Phpstan running under Php7 reports no errors. However, running under Php8, it reports 100 (!) errors. The vast majority of these are due to two reasons:
- renaming parameters in Php builtin functions in preparation for named parameters.
- using the new class GdImage rather than type resource as the argument type for many image-based functions.
Regardless of the cause, this will be a problem sooner or later. This PR is an attempt to get ahead of that problem. For source members, it mostly adds annotations or updates doc-blocks. Only 2 members have changes to executable code, and these are very minor - BitWise and Writer/Xlsx. For test members, all baseline errors are deleted and the code is fixed. Php7 and Php8 both report no errors with this configuration.
Initial implementation of Excel's tables feature (i.e. Select Home >
Format as Table in Excel App).
Tables are similar to AutoFilter but tables have other advantages like
named ranges, easy formatting, totals row and header row with filter.
Tables can also be converted to charts and pivot tables easily.
Usage:
$table = new Table();
$table->setName('Sales_Data');
$table->setRange('A1:D17');
$spreadsheet->getActiveSheet()->addTable($table);
In this Commit:
- Added Table API with initial support for header and totals row.
- Added complete styling options for Table.
- Added Xlsx Writer for Table.
- Added samples.
- Covered with unit tests.
To be done:
- Filter expressions similar to AutoFilter.
- Precalucate formulas for totals row (Check sample 2).
- Table named ranges in formulas and calculation.
Mark Baker
MarkBaker
oleibman
aswinkumar863
Kevin Bond
aswinkumar863