This queue is for tickets about the Spreadsheet-ParseExcel CPAN distribution.
Maintainer(s)' notes
If you are reporting a bug in Spreadsheet::ParseExcel here are some pointers
1) State the issues as clearly and as concisely as possible. A simple program or Excel test file (see below) will often explain the issue better than a lot of text.
2) Provide information on your system, version of perl and module versions. The following program will generate everything that is required. Put this information in your bug report.
#!/usr/bin/perl -w
print "\n Perl version : $]";
print "\n OS name : $^O";
print "\n Module versions: (not all are required)\n";
my @modules = qw(
Spreadsheet::ParseExcel
Scalar::Util
Unicode::Map
Spreadsheet::WriteExcel
Parse::RecDescent
File::Temp
OLE::Storage_Lite
IO::Stringy
);
for my $module (@modules) {
my $version;
eval "require $module";
if (not $@) {
$version = $module->VERSION;
$version = '(unknown)' if not defined $version;
}
else {
$version = '(not installed)';
}
printf "%21s%-24s\t%s\n", "", $module, $version;
}
__END__
3) Upgrade to the latest version of Spreadsheet::ParseExcel (or at least test on a system with an upgraded version). The issue you are reporting may already have been fixed.
4) Create a small example program that demonstrates your problem. The program should be as small as possible. A few lines of codes are worth tens of lines of text when trying to describe a bug.
5) Supply an Excel file that demonstrates the problem. This is very important. If the file is big, or contains confidential information, try to reduce it down to the smallest Excel file that represents the issue. If you don't wish to post a file here then send it to me directly: jmcnamara@cpan.org
6) Say if the test file was created by Excel, OpenOffice, Gnumeric or something else. Say which version of that application you used.
7) If you are submitting a patch you should check with the maintainer whether the issue has already been patched or if a fix is in the works. Patches should be accompanied by test cases.
Asking a question
If you would like to ask a more general question there is the Spreadsheet::ParseExcel Google Group.
Owner: |
Nobody in particular
|
Requestors: |
joseph.maniaci.ctr [...] mda.mil
|
Cc: |
|
AdminCc: |
|
|
Severity: |
(no value)
|
Broken in: |
(no value)
|
Fixed in: |
(no value)
|
|
Thu Nov 03 13:49:38 2011
joseph.maniaci.ctr [...] mda.mil - Ticket created
So I am using...
Perl Version: 5.012003
MSWin32
Spreadsheet::ParseExcel 0.59
Scalar::Util 1.23
Spreadsheet::WriteExcel 2.37
Parse::RecDescent 1.965001
File::Temp 0.22
OLE::Storage_Lite 0.19
IO::Stringy 2.110
So I have this very weird issue where a cell is quasi-defined and quasi-undefined.
Whereas most implementations iterate through the cells using
My $cell = $worksheet->get_cell( $row, $col);
Next unless $cell;
My implementation is
If( defined $worksheet->get_cell($row, $col)
{
Do stuff
$newworksheet->write($row,$col, $cell->value(), $newformat);
}
Else
{
$newworksheet->write($row, $col, $undef);
}
So the problem is that I have a cell that is defined; Within the bounds of rows and columns and has data just like any other cell, and yet it keeps going into the above else statement. Not only that but I used Padre to step through my code and eventually I entered the worksheet.pm file and entered the get_cell function and the bad cell behaved just as the good cells, it entered the
Else
{
Return $self->{Cells}->[$row]->[$col];
}
So it seems that worksheet.pm agrees that it is a defined cell. Yeh, when I step out of the get_cell() function and back to my code, it takes me to my else statement for undefined cells. Even more interesting is that I have 12 worksheets with the exact same column and row format, just different data, and two out of the twelve worksheets behave this way.
If absolutely necessary I can try to get the problematic excel spreadsheet, but it is on a classified network, so it might take some time. I was just hoping that I made a very simple mistake somewhere. I am also working on getting the new xlsx parse module to see what kind of difference it makes.
Thank you for any assistance.
Joseph M. Maniaci
Intern
Northrop Grumman Information Systems
DEPO/ Event Support
Fri Nov 04 06:22:28 2011
jmcnamara [...] cpan.org - Correspondence added
On Thu Nov 03 13:49:38 2011, joseph.maniaci.ctr@mda.mil wrote:
Show quoted text> So the problem is that I have a cell that is defined; Within the
> bounds of rows and columns and has data just like any other cell,
> and yet it keeps going into the above else statement. Not only that
> but I used Padre to step through my code and eventually I entered
> the worksheet.pm file and entered the get_cell function and the bad
> cell behaved just as the good cells, it entered the
>
> Else
> {
> Return $self->{Cells}->[$row]->[$col];
> }
>
> So it seems that worksheet.pm agrees that it is a defined cell.
Hi Joseph,
Thank you for the very detailed bug report.
In relation to the above else statement the module will enter that
else() statement regardless of whether the cells is the defined or not
(and the previous bound checks have been satisfied). If the cell isn't
defined then it returns undef since there isn't anything in
$self->{Cells}->[$row]->[$col].
Show quoted text> when I step out of the get_cell() function and back to my code, it
> takes me to my else statement for undefined cells. Even more
> interesting is that I have 12 worksheets with the exact same column
> and row format, just different data, and two out of the twelve
> worksheets behave this way.
If I was to be purely logical about this I would say that it means that
the cell doesn't contain data. However, there is clearly some factor at
play here.
One possible explanation is that Excel sometimes rearranges the order of
the worksheets internally so if you think that you are reading sheet n
you may actually be getting data from sheet n+/-1.
One useful way to debug this, or at least sanity check the data is to
use the display_text_table.pl example program that come with ParseExcel
to see if the layout of data that the module sees is that same as the
layout in Excel:
http://cpansearch.perl.org/src/JMCNAMARA/Spreadsheet-ParseExcel-0.59/examples/display_text_table.pl
If that doesn't highlight the issue then let me know and we will try
something else.
Regards,
John.
--
Fri Nov 04 06:22:34 2011
The RT System itself - Status changed from 'new' to 'open'
Fri Nov 11 11:19:29 2011
joseph.maniaci.ctr [...] mda.mil - Correspondence added
Thanks for the reply, I actually printed out the worksheet name every time just to be sure, I also ran the display_text_table.pl on the excel spreadsheet and the two cells have the data there just as they should.
I have even tried removing all formatting from the entire excel spreadsheet and it has no effect as well.
Thanks again.
Show quoted text-----Original Message-----
From: John McNamara via RT [mailto:bug-Spreadsheet-ParseExcel@rt.cpan.org]
Sent: Friday, November 04, 2011 4:23 AM
To: Maniaci, Joseph CTR MDA/DTGT/DES
Subject: [rt.cpan.org #72146] Potential bug with ParseExcel
<URL:
https://rt.cpan.org/Ticket/Display.html?id=72146 >
On Thu Nov 03 13:49:38 2011, joseph.maniaci.ctr@mda.mil wrote:
> So the problem is that I have a cell that is defined; Within the
> bounds of rows and columns and has data just like any other cell,
> and yet it keeps going into the above else statement. Not only that
> but I used Padre to step through my code and eventually I entered
> the worksheet.pm file and entered the get_cell function and the bad
> cell behaved just as the good cells, it entered the
>
> Else
> {
> Return $self->{Cells}->[$row]->[$col];
> }
>
> So it seems that worksheet.pm agrees that it is a defined cell.
Hi Joseph,
Thank you for the very detailed bug report.
In relation to the above else statement the module will enter that
else() statement regardless of whether the cells is the defined or not
(and the previous bound checks have been satisfied). If the cell isn't
defined then it returns undef since there isn't anything in
$self->{Cells}->[$row]->[$col].
> when I step out of the get_cell() function and back to my code, it
> takes me to my else statement for undefined cells. Even more
> interesting is that I have 12 worksheets with the exact same column
> and row format, just different data, and two out of the twelve
> worksheets behave this way.
If I was to be purely logical about this I would say that it means that
the cell doesn't contain data. However, there is clearly some factor at
play here.
One possible explanation is that Excel sometimes rearranges the order of
the worksheets internally so if you think that you are reading sheet n
you may actually be getting data from sheet n+/-1.
One useful way to debug this, or at least sanity check the data is to
use the display_text_table.pl example program that come with ParseExcel
to see if the layout of data that the module sees is that same as the
layout in Excel:
http://cpansearch.perl.org/src/JMCNAMARA/Spreadsheet-ParseExcel-0.59/examples/display_text_table.pl
If that doesn't highlight the issue then let me know and we will try
something else.
Regards,
John.
--
Tue Mar 11 15:11:52 2014
DOUGW [...] cpan.org - Correspondence added
On Thu Nov 03 13:49:38 2011, joseph.maniaci.ctr@mda.mil wrote:
Show quoted text>
> Else
> {
> Return $self->{Cells}->[$row]->[$col];
> }
>
> So it seems that worksheet.pm agrees that it is a defined cell. Yeh,
No, it just means that $row, $col, and the worksheet's MaxRow and MaxCol are defined, and that $row and $col are between the appropriate Min(Row/Col)/Max(Row/Col) range. Either the cell does not have data, or it is not being parsed properly from the spreadsheet. Will need a sample spreadsheet and test script if there's any hope of reproducing this. Hopefully you can scrub any secret data from the problem spreadsheet and still experience the issue. Otherwise will probably have to close this issue.