For (still) unknown reasons, PHPExcel detects a wrong field type.
If there is no BSE Index, we will fail here and other fields are not read.
So if the BSE Index < 1, continue with the next field.
TODO: Why is there no BSE Index?
Is this a new Office Version?
Password protected field?
More likely : a uncompatible picture
PHP Notice: Undefined offset: -1 in Classes/PHPExcel/Reader/Excel5.php on line 1063
PHP Fatal error: Call to a member function getBlipType() on a non-object in Classes/PHPExcel/Reader/Excel5.php on line 1064
removeColumn doesn't remove all cells, because CacheBase::deleteCacheData only unsets cell data if they are objects.
But cached cell data could be arrays.
I moved the unset from inside the if block (line 150 ff) to after the if block.
We wrapped lines to make easier the source easier to read, and to have more manageable diffs.
This was done with something like:
```sh
pandoc --wrap=auto --atx-headers -f markdown -t markdown-fenced_code_attributes+pipe_tables+raw_html+intraword_underscores`
```
We aim for long pages instead of several small one, to make
`CTRL+F`ing easier and URL less prone to changes in the future.
There is still way to improve it though...
BaseReader called `isValidFormat` despite it doesn't require it to be
implemented. Instead we replaced `isValidFormat` by a proper implementation
of `canRead` in each classes. This also remove the semantic amibguity between
those two methods.
FIX#32
This is to fix the situation when cells merged vertically are ignored in columns auto size calculations.
I also removed $calculateMergeCells param as it wasn't used and I believe the only situation when you
want to calculate the width of merged columns has been covered here (and there's no reason to not calculate it).
FIX#46
Some references to classes were incorrectly assumed to be a reference
to self, whereas they were references to classes in global namespace
outside of this project.
FIX#37
GD is implicitly required for saving images anyway, this exception when
it's not loaded simply gives more information on what to do if the
execution flow reaches a places that depends on a function from GD.
```php
<?php
$array = array(
'str' => 'foo',
'num' => 12345,
'null' => NULL,
);
print intval(isset($array['null'])) . PHP_EOL;
print intval(array_key_exists($array['null'])) . PHP_EOL;
print intval(isset($array['num'])) . PHP_EOL;
print intval(array_key_exists($array['num'])) . PHP_EOL;
print intval(isset($array['str'])) . PHP_EOL;
print intval(array_key_exists($array['str'])) . PHP_EOL;
```
Only for this special case, you need array_key_exists(), else avoid it as it is
painfully slow and hurts your performance.
Signed-off-by: Roland Häder <roland@mxchange.org>
Remove the term "hack" from the source code to prevent it
from being flagged by malware scanners and audit tools (such as
the very popular myJoomla.com for Joomla sites)
Remove the term "hacked by" from the source code to prevent it
from being flagged by malware scanners and audit tools (such as
the very popular myJoomla.com for Joomla sites)
If a sheet name included an apostrophe and the sheet had print area
defined then the spreadsheet could not be saved because the cell
coordinates were mangled, eg:
'Fiche d''action'!$A$1:$N$19
wrongly became:
'Fiche d'$A$1:$N$19
Herman M. Hofman