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: |
tlhackque [...] yahoo.com
|
Cc: |
|
AdminCc: |
|
|
Severity: |
(no value)
|
Broken in: |
0.59 |
Fixed in: |
0.61 |
|
Wed Feb 26 13:30:11 2014
tlhackque [...] yahoo.com - Ticket created
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} ;
}
Thu Feb 27 13:46:20 2014
DOUGW [...] cpan.org - Correspondence added
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.
Thu Feb 27 13:46:20 2014
The RT System itself - Status changed from 'new' to 'open'
Thu Feb 27 22:27:16 2014
tlhackque [...] yahoo.com - Correspondence added
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.
Fri Feb 28 06:52:57 2014
jmcnamara [...] cpan.org - Correspondence added
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
Fri Feb 28 06:56:26 2014
jmcnamara [...] cpan.org - Correspondence added
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
Fri Feb 28 06:59:59 2014
jmcnamara [...] cpan.org - Correspondence added
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
Fri Feb 28 10:09:31 2014
tlhackque [...] yahoo.com - Correspondence added
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.
Tue Mar 04 19:00:43 2014
DOUGW [...] cpan.org - Correspondence added
Tue Mar 04 19:00:45 2014
DOUGW [...] cpan.org - Status changed from 'open' to 'resolved'