* Validate POST Input in Sample 45
Errors will result if inputs are not numeric.
* Update 45_Quadratic_equation_solver.php
---------
Co-authored-by: Owen Leibman <owenleibman@fico.com>
PR #4132 was needed for release 2.2.2 because of a problem with Excel 2016 introduced with 2.2.0. This is a minor tweak to that change - a little simpler, and possibly beneficial if the spreadsheet uses split screens.
Fix#1402, another in our "better late than never" series. Stalebot closed it in May 2020, and I have reopened it. @ljcag submitted the issue, and PR #1403 to resolve it, also marked stale. That change is more complicated than this one. Since there were no tests in that PR, and since this PR solves the original problem (test added), I will stick with this version, but will continue to study 1403 before merging.
This is also another in the "Excel doesn't believe in complete documentation" series. (See issue #3802 for a similar example.) Nothing that I have seen in the documentation suggests that a number will not match a numeric string, but that seems clearly to be the case. Despite the lack of complete documentation, PhpSpreadsheet implemented VLOOKUP with that in mind. Unfortunately, it did so by using `is_numeric` on its comparands, and so treats numeric strings as if they were numbers. This PR replaces those tests with `is_int() || is_float()`. The earlier PR used `is_string()` instead as a proxy for "not numeric" but that required other changes.
When String Value Binder converts a numeric value to text, the resulting spreadsheet will be full of little green triangles to indicate to the end user that something might be wrong. It is unlikely that a spreadsheet created in this manner needs that visual clutter. This PR adds a property and setter (I can't really think of a good use case for a getter) to suppress it. Suppression should arguably be the default, but, for now, I will avoid any BC problems by leaving non-suppression as the default.
This supersedes PR #607 by @christian-forgacs, who deserves all the credit for reporting the problem and devising the solution. The PR went stale in 2018, and it is just easier to resubmit a clean version rather than clean up the old one. Among the suggestions in the PR was that you should try to create a spreadsheet from scratch to demonstrate the problem rather than supply one. However, my attempts to match the failing spreadsheet do not have a problem when they are read. So, a supplied spreadsheet it is.
Fix#1570. No sample spreadsheet was supplied with that issue, but I am almost certain that this is another example of the same problem. I am removing the stale label from that issue; it will be closed properly when this PR is merged.
Suggested by PR #1321 from @rtek, which was marked stale in March 2020. If the xml for a cell does not specify a type, PhpSpreadsheet has been using string; however, Excel uses numeric. PhpSpreadsheet will be changed to do the same as Excel. In theory, this is a BC break; in practice, it is doubtful that anyone will be adversely affected. No changes in the existing unit tests were required. The new test from rtek does demonstrate the change in behavior; however, the new behavior is certainly what a user would expect to happen. Unlike the original PR, this one is restricted to Xlsx Reader; I do not believe that any logic change is needed for Writer. (N.B. - changing Writer to use class constants rather than literals is a good idea, but, with no other logic change in this version, it seems risky - I may do that as separate PR.)
I am becoming concerned with the increasing run-time of php-cs-fixer, especially since it can time out. Some relief may come from PR #4118, but that won't be merged for some time, if ever. So, bump up the timeout period now. Also replace properties which php-cs-fixer has deprecated with their non-deprecated equivalents. No change to any source code.
PHPCompatibility (versions check) erroneously flags the use of $this in enumerations. They fixed it in their development branch in October 2022. But they haven't had a release since 2019!
oleibman
dependabot[bot]
Marc Bennewitz
murongshaozong