Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Handling child process and close window exits in Perl/Tk

by rcseege (Pilgrim)
on Oct 14, 2006 at 17:37 UTC ( #578304=note: print w/replies, xml ) Need Help??

in reply to Handling child process and close window exits in Perl/Tk

The second is standalone because it's general purpose and I didn't want to rewrite it every place I want to use it.

Points for reuse, but I think your approach has lots of unintended consequences that will require the parent and child to be more complex as a result. You can have the child exit with various codes that your parent can interpret and act accordingly, and that's not really that complex, but will the child be providing other user-supplied information back to the parent? Will the child be around for long time? For example, under your current strategy, your parent will not be able to receive events until the child is done (exits), unless you're using something like fileevent.

My suggestion would be to create a module out of your reused second window, and treat the second window as a dialog box. for your parent. Your code will be much simpler as a result. Update: (see my followup for examples)

is there a way to catch that 'x' signal?

Yes. What you're looking for is something like this:

use Tk; my $mw = MainWindow->new; $mw->protocol(WM_DELETE_WINDOW => sub { print "Exiting appliction!\n"; exit; }); MainLoop;

Replies are listed 'Best First'.
Re^2: Handling child process and close window exits in Perl/Tk
by rcseege (Pilgrim) on Oct 14, 2006 at 20:45 UTC

    Update: did some minor tag/formatting edits

    There are lots of ways to reuse code in modules. My preferred approach when using Tk is to extend existing Tk widgets. I will either extend Frame and create Composites (or megawidgets as they are sometimes called), or I will extend other widgets that do most of what I want.

    Typically, I will also throw most non-gui functionality into other non-tk modules, and I will try to keep the two varieties of modules as separate as possible with no bleedover. I do this to make it easier to test one without the other, and also in case I decide to move to a different kind of GUI at a later time.

    I will even adhere to this separation within a single script if the appliciation is anything more than a trival example or snippet... but that mostly boils down to personal taste on my part, and there are many other approaches you could take. So given your case (and without knowing more details) I might have done something like this:


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://578304]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (5)
As of 2018-02-22 23:10 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (300 votes). Check out past polls.