Bug fix for write() module in Worksheet.pm

[stevencothren]

Change so that write() will not call write_number() when the value is too large for Perl to handle or when the format has been set to text (@).

I came across this when calling write_row() and one of the fields is a Secondary Number (like Apt #). Some of the information is in the format of '2E310' which write() treats as a scientific number, but it is too big for Perl so write_number() ends up making it an 'Infinity'.

I also added code so that write() won't call write_number() if the format has been set to text (@). I thought of this since the above fix really just happens to fix my issue as the "number" is so large. It doesn't fix cases like '2E10' that aren't too big. I would expect that if I set a format to text then it will be written as text not as a number.

[stevencothren]

It might be worth considering adding the 'Infinity' check to write_number() and have it return an error if that happens. When it does happen the spreadsheet gets built, but Excel complains about corrupted data and forces you to 'repair' it before opening.

[jmcnamara]

Hi Steven,

Thanks for the patch.

This is definitely a bug. The module shouldn't ever produce an Excel file that causes "Repair" errors. I've raised a new issue for this: #73.

However, I think this should be fixed in write_number() and not write(). The write() method is doing what the API says it does which is to convert something that looks like a number to a number. The fact that it isn't actually a number is the fault of write_number().

So, I'm going to close this PR and deal with the issue in #73.

If you want to work around this in the meantime have a look at the add_write_handler() method which allows you to modify the behaviour of write().

Regards,

John