When closing DOS window...

[Richard S Beckett]

Guys,

I ahve written a script that runs in a DOS window, and parses a log file
into Excel.

If a user decides to terminate the script whilst running, the Excel process
gets left running, and messes up the operation of the script, and Excel
afterwards.

I invoke Excel like this:
my $excel;
eval {$excel = Win32::OLE->GetActiveObject('Excel.Application')};
die "WARNING! Excel not installed" if $@;
unless (defined $excel) {
$excel = Win32::OLE->new('Excel.Application', sub {$_[0]->Quit;}) or die
"ERROR, cannot start Excel";
}

I have an END block that closes Excel down, and I have successfully trapped
Control C so that the END block gets executed and Excel is closed properly.

However, I have found that if the user presses the X button on the window,
then I am again left with an orphan Excel process.

Should I start Excel differently so that it terminates when the script does?

Alternatively, can anyone give me any pointers on how to trap the user
clicking on the X so that I can ensure that my END block is run, like I now
do for control C?

Thanks.

 

[James Willmore]

On Thu, 18 Dec 2003 13:24:30 -0000

Should I start Excel differently so that it terminates when the
script does?

Alternatively, can anyone give me any pointers on how to trap the
user clicking on the X so that I can ensure that my END block is
run, like I now do for control C?

The example given in the Win32::OLE documentation uses Excel - but has
the user open and close Excel, not the script. That's the route I
went with one of the few Win32 scripts I've written. Will that help?

Another may be to use one of the Spreadsheet modules to do what you
need to do - removing the actual Excel application from the mix.

http://search.cpan.org/author/KWITKNR/Spreadsheet-ParseExcel-0.2602/ParseExcel.pm

I realize this isn't much to go on, but that's what experience I've
had and just figured I'd throw it out there. Others may have better
options.

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
You will be a winner today. Pick a fight with a four-year-old.

 

[Thomas Kratz]

Guys,

I ahve written a script that runs in a DOS window, and parses a log file
into Excel.

If a user decides to terminate the script whilst running, the Excel process
gets left running, and messes up the operation of the script, and Excel
afterwards.

I invoke Excel like this:
my $excel;
eval {$excel = Win32::OLE->GetActiveObject('Excel.Application')};
die "WARNING! Excel not installed" if $@;
unless (defined $excel) {
$excel = Win32::OLE->new('Excel.Application', sub {$_[0]->Quit;}) or die
"ERROR, cannot start Excel";
}

This way you are first trying to use an already opened Excel. If this
fails you will start a new instance.

I have an END block that closes Excel down, and I have successfully trapped
Control C so that the END block gets executed and Excel is closed properly.

However, I have found that if the user presses the X button on the window,
then I am again left with an orphan Excel process.

The X button closes down the command shell running your script. The script
is killed immediately.

Should I start Excel differently so that it terminates when the script does?

You have to create a watchdog for your script that kills Excel, when your
script should be killed.

One solution could be:

- create a master Perl script, that runs in the background without a
window (use wperl.exe instead of perl.exe)
- let it start Excel (with Win32:rocess, keep the object to kill
it later) or get the PID of a already running Excel (not sure how
to do that), You can create an Win32:rocess Object with a PID.
- let it start a new cmd interpreter with your script (wait for
this process to end)
- your script should just connect to Excel with
Win32::OLE->GetActiveObject not create a new one with
Win32::OLE->new
- when the master script regains control, all you have to do is kill
Excel, if it is still running.

But what if the user kills the master process with TaskManager?

I personally would probably do the user interaction with Tk (with
wperl.exe no cmd window involved). You can trap the closing of Tk windows.

Thomas

 

[Malcolm Dew-Jones]

Richard S Beckett ([email protected]) wrote:
: Guys,

: I ahve written a script that runs in a DOS window, and parses a log file
: into Excel.

: If a user decides to terminate the script whilst running, the Excel process
: gets left running, and messes up the operation of the script, and Excel
: afterwards.

: I invoke Excel like this:
: my $excel;
: eval {$excel = Win32::OLE->GetActiveObject('Excel.Application')};
: die "WARNING! Excel not installed" if $@;
: unless (defined $excel) {
: $excel = Win32::OLE->new('Excel.Application', sub {$_[0]->Quit;}) or die
: "ERROR, cannot start Excel";
: }

: I have an END block that closes Excel down, and I have successfully trapped
: Control C so that the END block gets executed and Excel is closed properly.

: However, I have found that if the user presses the X button on the window,
: then I am again left with an orphan Excel process.

The command line program does not (normally, ever?) see the controlling
events sent to the dos-box window. (After all, the dos box is emulating a
window-less environment.)

: Should I start Excel differently so that it terminates when the script does?

Perhaps an Excel macro could monitor the dos-box and shut down excel
if the dos-box app goes away. Total guess, but I wonder if there's a
"OnOLETimeout" or similar event defined for excel.

: Alternatively, can anyone give me any pointers on how to trap the user
: clicking on the X so that I can ensure that my END block is run, like I now
: do for control C?

Spawn a second process and start excel from within that process instead.
Have that process provide its own window. If the user closes the dos-box
then your app still runs. If they close the (second) window then you
receive the window close and shut down excel.

You don't need a ful fledged window, a modeless dialog box would be
enough. (I'm not sure if/how a console program shows a modeless dialog
though - a regular dialog is very easy to display, at least in the active
state distro.)

Alternately, the second program could run in the background and monitor
the first (dos-box) process, and shut both itself and excel down if the
dos-box goes away.

$0.02

 

[Ben Morrow]

However, I have found that if the user presses the X button on the window,
then I am again left with an orphan Excel process.

"Windows cannot shut down this program automatically. It is
recommended that you exit this program with its quit or exit command"

If a user ignores a warning like that, they get what they deserve .

Ben

 

[R Solberg]

One solution could be:

- create a master Perl script, that runs in the background without a
window (use wperl.exe instead of perl.exe)

I would like to learn more about wperl.exe. Does anyone know of a man
page or something else I can read about wperl.exe?
Thanks.