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: 93393
Status: resolved
Priority: 0/
Queue: Spreadsheet-ParseExcel

People
Owner: Nobody in particular
Requestors: tlhackque [...] yahoo.com
Cc:
AdminCc:

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



Subject: Unable to determine active worksheet
Another in the series: It turns out to be useful to know which worksheet was active (open) when the workbook was saved, as users may expect this to be the default worksheet that is processed by the application. Turns out to be easy to get. (Actually, the WINDOW1 and WINDOW2 records have other interesting data, but they'll wait until I need them.) Adds $workbook->get_active_sheet; returns sheet number (or, rarely: undef - workbooks that don't have the record field include those prior to BIFF5). This is a new record type (to S:P:E), so it's another easy addition. Usual patch: package ExcelToHtml::Parser; # Hacks to get additional information from the spreadsheets # # These use the Spreadsheet::ParseExcel routines for everything # else to ensure that any bugs there aren't replicated. our @ISA = (qw/Spreadsheet::ParseExcel/); sub new { my $class = shift; $Spreadsheet::ParseExcel::ProcTbl{0x3D} = \&_subWindow1; return $class->SUPER::new(@_); } sub _subWindow1 { my ( $oBook, $bOp, $bLen, $sWk ) = @_; return if ( $oBook->{BIFFVersion} <= Spreadsheet::ParseExcel::verBIFF4() ); my($iHpos, $iVpos, $iWidth, $iHeight, $iOptions, $iActive, $iFirstTab, $iNumSelected, $iTabBarWidth ) = unpack( "v9", $sWk ); $oBook->{ActiveSheet} = $iActive; } package Spreadsheet::ParseExcel::Workbook; =head2 get_active_sheet() Return the (0-based) number of the active (open) worksheet (at the time the workbook was saved. May return undef. =cut sub get_active_sheet { my $workbook = shift; return $workbook->{ActiveSheet} ; }
On Wed Feb 26 13:30:11 2014, tlhackque wrote: Show quoted text
> Another in the series:
I think for this and all of the other 'expose another attribute' enhancements that require handling another event, there should be some kind of plugin rather than unconditionally adding more events to the global event handler since 99% of the time this is not needed, so why slow down the parsing 100% of the time. I'm not yet sure exactly what kind of plugin should be implemented, but will think about it for the time being.
Subject: Re: [rt.cpan.org #93393] Unable to determine active worksheet
Date: Thu, 27 Feb 2014 22:26:55 -0500
To: bug-Spreadsheet-ParseExcel [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
On 27-Feb-14 13:46, Douglas Wilson via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=93393 > > > On Wed Feb 26 13:30:11 2014, tlhackque wrote:
>> Another in the series:
> I think for this and all of the other 'expose another attribute' enhancements that require handling another event, there should be some kind of plugin rather than unconditionally adding more events to the global event handler since 99% of the time this is not needed, so why slow down the parsing 100% of the time. I'm not yet sure exactly what kind of plugin should be implemented, but will think about it for the time being. >
Most don't require another event - I simply had to hook the existing ones. Two do. I doubt that the slowdown is measurable, but I'm open to another approach. These are pretty much check a bit, store a value - it's not that the routines do a lot of work. A plugin with 'register_handler(code, \&sub) could be done. But the result will be hard to document if it's to stay compatible with the current API. It will seem arbitrary which routines need the plugin to be active, and which don't. Autoload won't help, because by the time someone calls get_foo, the parsing has been done. Note that there are many less useful items in the current code - e.g. is_print_comments, when comment's can't be retrieved. 'new' and 'old' may make sense to PSE maintainers, but not to users. So I don't think there's a lot of payback for adding that complexity; personally I'd rather you invest in the harder issues - like making the parser in P:S:E:Utility work. -- This communication may not represent my employer's views, if any, on the matters discussed.
On Thu Feb 27 13:46:20 2014, DOUGW wrote: Show quoted text
> I think for this and all of the other 'expose another attribute' > enhancements that require handling another event, there should be some > kind of plugin
Hi, I think that is a very good idea. There could be a public method to add callbacks to the %ProcTbl hash. The %ProcTbl hash should then be localised to the object rather than the class. That way users don't need a maintainer to add/fix functionality. John
On Wed Feb 26 13:30:11 2014, tlhackque wrote: Show quoted text
> > Adds $workbook->get_active_sheet; returns sheet number (or, rarely: > undef - workbooks that don't have the record field include those prior > to BIFF5).
Hi Timothe, I think that code changes like this should be accompanied by tests cases. Especially if you want the changes to be upstreamed into the CPAN module. There are several similar test cases that you could copy and use with sample Excel files. John
Doug, Timothe, BTW just a general point. Most of the existing code style is inherited ugly camelcase. Feel free to improve the style as you modify the code. John
Subject: Re: [rt.cpan.org #93393] Unable to determine active worksheet
Date: Fri, 28 Feb 2014 10:09:21 -0500
To: bug-Spreadsheet-ParseExcel [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
On 28-Feb-14 06:56, John McNamara via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=93393 > > > On Wed Feb 26 13:30:11 2014, tlhackque wrote:
>> Adds $workbook->get_active_sheet; returns sheet number (or, rarely: >> undef - workbooks that don't have the record field include those prior >> to BIFF5).
> Hi Timothe, > > I think that code changes like this should be accompanied by tests cases. Especially if you want the changes to be upstreamed into the CPAN module. > > There are several similar test cases that you could copy and use with sample Excel files. > > John
Yes, I would like the changes upstreamed into CPAN - otherwise I wouldn't bother publishing them. If they're in CPAN, I don't have to patch S:P:E at runtime in my application; other users get the benefit of the features; and everyone's life is simpler. I created test cases for get_active_sheet, color_idx_to_rgb, get_tab_color, is_sheet_hidden, is_row_hidden, is_col_hidden and committed them to my github repo. (https://github.com/tlhackque/spreadsheet-parseexcel) I'm a bit confused - who is maintaining the module? John - you wrote that you'd put it up for adoption and it was unmaintained due to lack of time; I assumed Doug took it on when he started responding to my tickets. I'd like a plan. I really don't want to do everything three times - once as a runtime patch in my project, once in a ticket, and again in git. I'm really focused on my project - but happy to contribute S:P:E patches, since if they will drive a release, I won't have to patch S:P:E when I release my code. It sounds as though you both prefer patches in git, which is fine. Who should get pull requests? Do you want every issue in an rt ticket? If a ticket, do you also want pull requests? Can we keep it simple? What's the easiest for everyone? I vote for just git... if one or the other of you will commit to releasing P:S:E with the (agreed-upon) patches when my work stabilizes and is ready for release. I hope in the next few days - I'm getting close. Then I can do my work against my git repo, you can easily merge patches, and everyone else will get a release sometime soon. Second choice would be patches in git, with a copy of the commit message in rt. Third choice is just focus on my project - and forget upstreaming patches. To simplify my list of open tickets: * It would be a big help if rt#93142 (Date format strings) could be addressed. I have work-arounds or patches for everything else. * The work-around for 93067 (api for accurate width and height) is imperfect. I could develop a real patch. Thanks. -- This communication may not represent my employer's views, if any, on the matters discussed.
Fixed in 0.61