Re^2: Excel Win32::OLE - copy data problem

in reply to Re: Excel Win32::OLE - copy data problem
in thread Excel Win32::OLE - copy data problem

Well, I did more research on that.. The problem seems to come from this line in the code

my ($last2_row,$last2_col) = sub_find_last($New_Sheet);
[download]

This line does not seem to work..Strange, as a similar command works 2 line above :(

Raghu

Comment on Re^2: Excel Win32::OLE - copy data problem Download Code

Replies are listed 'Best First'.
Re^3: Excel Win32::OLE - copy data problem by roboticus (Chancellor) on Dec 08, 2009 at 15:20 UTC
imrags: I doubt it's that line, as that line doesn't attempt to treat anything as a hash reference. Run your program with the debugger, it's not hard, and you'll find the problem pretty easily. First, invoke your program under the debugger: $ perl -d dbg.pl Loading DB routines from perl5db.pl version 1.3 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(dbg.pl:5): my $t; DB<1> [download] At this point, perl is waiting to execute the first statement of your program, "my $t;" in this case. Since you have a suspicious line, you can tell perl to execute your program until it enters the sub_find_last subroutine by first setting a breakpoint in the subroutine, and then telling perl to run as normal, like this: `DB<1> b sub_find_last DB<2> r main::sub_find_last(dbg.pl:31): my $X = shift; DB<2>` [download] Now the debugger is in the sub_find_last routine, ready to execute the first line. You can execute that line (with the 'n' (next) command, and then see what was loaded into $X with the 'p' (print) command, like so: DB<2> n main::sub_find_last(dbg.pl:32): return if !defined $X; DB<2> p $X Use of uninitialized value $X in print at (eval 5)[/usr/lib/perl5/5.10 +/perl5db.pl:638] line 2. at (eval 5)[/usr/lib/perl5/5.10/perl5db.pl:638] line 2 eval '($@, $!, $^E, $,, $/, $\\, $^W) = @saved;package main; $ +^D = $^D \| $DB::db_stop; print {$DB::OUT} $X; ;' called at /usr/lib/perl5/5.10/perl5db.pl line 638 DB::eval called at /usr/lib/perl5/5.10/perl5db.pl line 3436 DB::DB called at dbg.pl line 32 main::sub_find_last(undef) called at dbg.pl line 8 DB<3> [download] Any time you want, you can use the 'h' command to get a brief overview of the commands available in the debugger interface. If you spend a little time learning how to use the debugger, you'll greatly increase your development speed. Why is that? First, you'll be able to see exactly what's happening, rather than guessing and hoping. Second, when you have a data problem, you can immediately repair the data item and continue execution rather than edit the program restart and work through all the inputs to get back to the same spot. Third (and most importantly, IMHO), you'll start getting a better "feel" for the language, which will help you avoid making many mistakes in the first place. So go on, give it a go. If you get stuck on something, we'll be glad to help out. I'd first set a breakpoint (the 'b' command) on the line: `if($select_sheet->Range("A1")->{Value} =~ /Step/i)` [download] Then, since you know the first two sheets process normally (I think, based on the output you showed in the OP), you can let perl process the first two sheets normally by using the run ('r') command twice. The first time, it'll process the first sheet, go back to the beginning of the loop, and break. The second 'r' will process the second sheet, go back to the top of the loop and break again. Then you can single-step through the program and find out what beaks. Once you get used to the debugger, you'll be able to find and repair your programs pretty quickly. Be sure to use the help ('h') command to see how to use the common commands, and read (`perldoc perldebug`) for more details and information on the less-common commands. ...roboticus	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Excel Win32::OLE - copy data problem
by roboticus (Chancellor) on Dec 08, 2009 at 15:20 UTC

imrags

I doubt it's that line, as that line doesn't attempt to treat anything as a hash reference.

Run your program with the debugger, it's not hard, and you'll find the problem pretty easily. First, invoke your program under the debugger:

$ perl -d dbg.pl

Loading DB routines from perl5db.pl version 1.3
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.
main::(dbg.pl:5):       my $t;
  DB<1>
[download]

At this point, perl is waiting to execute the first statement of your program, "my $t;" in this case. Since you have a suspicious line, you can tell perl to execute your program until it enters the sub_find_last subroutine by first setting a breakpoint in the subroutine, and then telling perl to run as normal, like this:

  DB<1> b sub_find_last
  DB<2> r
main::sub_find_last(dbg.pl:31):         my $X = shift;
  DB<2>
[download]

Now the debugger is in the sub_find_last routine, ready to execute the first line. You can execute that line (with the 'n' (next) command, and then see what was loaded into $X with the 'p' (print) command, like so:

  DB<2> n
main::sub_find_last(dbg.pl:32):         return if !defined $X;
  DB<2> p $X
Use of uninitialized value $X in print at (eval 5)[/usr/lib/perl5/5.10
+/perl5db.pl:638] line 2.
 at (eval 5)[/usr/lib/perl5/5.10/perl5db.pl:638] line 2
        eval '($@, $!, $^E, $,, $/, $\\, $^W) = @saved;package main; $
+^D = $^D | $DB::db_stop;
print {$DB::OUT}  $X;

;' called at /usr/lib/perl5/5.10/perl5db.pl line 638
        DB::eval called at /usr/lib/perl5/5.10/perl5db.pl line 3436
        DB::DB called at dbg.pl line 32
        main::sub_find_last(undef) called at dbg.pl line 8

  DB<3>
[download]

Any time you want, you can use the 'h' command to get a brief overview of the commands available in the debugger interface. If you spend a little time learning how to use the debugger, you'll greatly increase your development speed. Why is that? First, you'll be able to see exactly what's happening, rather than guessing and hoping. Second, when you have a data problem, you can immediately repair the data item and continue execution rather than edit the program restart and work through all the inputs to get back to the same spot. Third (and most importantly, IMHO), you'll start getting a better "feel" for the language, which will help you avoid making many mistakes in the first place.

So go on, give it a go. If you get stuck on something, we'll be glad to help out. I'd first set a breakpoint (the 'b' command) on the line:

if($select_sheet->Range("A1")->{Value} =~ /Step/i)
[download]

Then, since you know the first two sheets process normally (I think, based on the output you showed in the OP), you can let perl process the first two sheets normally by using the run ('r') command twice. The first time, it'll process the first sheet, go back to the beginning of the loop, and break. The second 'r' will process the second sheet, go back to the top of the loop and break again. Then you can single-step through the program and find out what beaks. Once you get used to the debugger, you'll be able to find and repair your programs pretty quickly.

Be sure to use the help ('h') command to see how to use the common commands, and read (perldoc perldebug) for more details and information on the less-common commands.

roboticus

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom