Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

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.

Report information
The Basics
Id: 72146
Status: open
Priority: 0/
Queue: Spreadsheet-ParseExcel

People
Owner: Nobody in particular
Requestors: joseph.maniaci.ctr [...] mda.mil
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Potential bug with ParseExcel
Date: Thu, 3 Nov 2011 11:49:22 -0600
To: "bug-Spreadsheet-ParseExcel [...] rt.cpan.org" <bug-Spreadsheet-ParseExcel [...] rt.cpan.org>
From: "Maniaci, Joseph CTR MDA/DTGT/DES" <joseph.maniaci.ctr [...] mda.mil>
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
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. --
Subject: RE: [rt.cpan.org #72146] Potential bug with ParseExcel
Date: Fri, 11 Nov 2011 09:19:06 -0700
To: "bug-Spreadsheet-ParseExcel [...] rt.cpan.org" <bug-Spreadsheet-ParseExcel [...] rt.cpan.org>
From: "Maniaci, Joseph CTR MDA/DTGT/DES" <joseph.maniaci.ctr [...] mda.mil>
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. --
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.