A follow-on activity to PR #5061. That PR added scrollbars to the dropdown lists when samples were run in a browser. Earlier changes had broken up a number of categories into multiple entries because the dropdown lists were too long and wound up truncated. With the scrollbars, it makes sense to re-consolidate many of those lists, such as ComplexNumbers, which are all essentially the same test as each other. Some break-ups are retained (e.g. Basic/1/2/3/4/5) because they differ substantially from sample to sample; that's kind of an arbitrary decision, but it will have to do for now. I also renamed some of the members so that like members sort together when listing the directory (e.g. all pivot table samples now start with `pvt`). The sample code is mostly unchanged; only the directory and/or member names are changed.
The download samples were moved to their own new directory, and now represent a complete set of all the write formats that we permit. Studying their code, an improvement for `Helper\Downloader` became evident. It had been used merely to copy an existing file to be downloaded. However, by changing the first parameter of `download` to be either the name of the file directory (the existing usage) *or* a `Writer` object poised to issue `save`, you can use it to download your spreadsheet without having to worry about the headers which the browser requires. It then becomes generally useful beyond being used in samples:
```php
$writer = new WriterType($spreadsheet);
$downloader = new Downloader($writer, 'suggestedFileName.xlsx');
$downloader->download();
```
The samples have become unwieldy when running them from a browser. In particular, the drop-down lists are fixed size with no scrolling, and many of them are now just too large. I have moved all the Calculation samples up a level, and broken several categories (Basic, Chart, DateTime, Engineering, Financial, and Reader) into several pieces.
Convert-Online (now found in the Engineering category) had a number of different problems which are now resolved. It is the only member with any significant code change.
* WIP Limited Support for Form Controls V2 (ListBox, Buttons, etc.)
This is a replacement for draft PR #2455 and draft PR #3127. There is some useful commentary in those PRs which I have mostly, but not entirely, duplicated below. Fix#2396. Fix#1770. Fix#2388.
A related problem is that the vml files used for the form controls sometimes contain invalid xml. Fix#3125 (rejected previous PR #1181 as too risky, issue was also reported as #170). Vml file should be valid Xml, but Excel can generate unclosed `<br>` tags, preventing Xlsx reader from reading file correctly. I believe a very narrowly targeted fix, changing `<br>` to `<br/>`, and only when reading vml files, probably mitigates the risk. The sample file formscomments.xlsx which is part of this change shows this problem with `Button 1` on sheet `Forms`; the spreadsheet was created with Excel 365, so the problem is not restricted to Excel 2013 as originally reported. A comment on PR 3127 indicates that other tags might be involved, but, without a file demonstrating that, I will restrict this change to br tags for now.
I am starting this out in draft status, and will probably leave it that way for some time. I'm not sure where we want to go with this. It fixes some problems, but in a limited manner, and creates some others. I'm not sure the pain of the others is balanced considering the limitations of the fix. If enough interest is generated as a result of this ticket being out there, we can proceed; if not, it probably isn't worth it.
This fix allows form control elements to be read in and written out. It does not allow you to add such elements, nor even to locate them or determine their properties (so you can't modify or delete them). Although it handles reading and writing of sheets containing both form controls and comments, it will probably create a corrupt spreadsheet if you try adding a new comment to a sheet with form controls - probably quite difficult to solve. Cloning the sheet probably won't work either - probably easier than the other. It is conceivable that we want to add a new property to the Xlsx Reader which turns the reading of form elements on or off (default=off), so that negative effects will be limited to those who have explictly opted in. The change in its current form does not implement such a property.
Because of its limitations, the change isn't really testable. As in some other recent installs, I have added a sample to demonstrate that it works correctly.
As it turns out, if we have a worksheet which contains both form controls and comments (see formscomments.xlsx which is part of this PR), PhpSpreadsheet already creates a corrupt file when it tries to load and save the spreadsheet with such a worksheet. With this change, the file is saved without corruption. This tilts things in favor of proceeding. I'm still not ready, but this will be an important consideration.
A sample file for issue #2621 illustrated a problem with shape files. Since they are involved here, I took a look at how the sample worked with this code. In master, and with this change, a corrupt file results. Fixing that is probably easier than the general problem of handling shape files, but it's an argument against moving this forward until the corruption problem can be addressed.
Fix#2661. A template including checkboxes was leading to file corruption solved by this PR. Another argument for moving forward.
* Improved Sample File, and Documentation
Add more realistic worksheet to spreadsheet. Document new feature, adding caveats to how it can be used.
oleibman