Revive Tk
Gerhard Reithofer
I found this bahaviour:
$>tclsh
% package require Tk
8.5.4
# close the root window by mouse
% canvas .c
can't invoke "canvas" command: application has been destroyed
% info patchlevel
8.5.4
Q: How can I bring Tk bck to life?
TIA
--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
Jonathan Bromley
<gerhard....@tech-edv.co.at> wrote:
>Hi all,
>I found this bahaviour:
>
>$>tclsh
>% package require Tk
>8.5.4
># close the root window by mouse
>% canvas .c
>can't invoke "canvas" command: application has been destroyed
>% info patchlevel
>8.5.4
>
>Q: How can I bring Tk bck to life?
I'd love to know this too. You can prevent the window
from being closed by a suitable
wm protocol . WM_DELETE_WINDOW what_to_do_on_close
but that does not get invoked when you do [destroy .]
programmatically, so that's not enough. I tried
package forget Tk
and various other things, but...
any hints welcomed!
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Don Porter
> On Wed, 10 Jun 2009 18:55:00 +0200, Gerhard Reithofer
> <gerhard....@tech-edv.co.at> wrote:
>
>> Hi all,
>> I found this bahaviour:
>>
>> $>tclsh
>> % package require Tk
>> 8.5.4
>> # close the root window by mouse
>> % canvas .c
>> can't invoke "canvas" command: application has been destroyed
>> % info patchlevel
>> 8.5.4
>>
>> Q: How can I bring Tk bck to life?
>
> I'd love to know this too. You can prevent the window
> from being closed by a suitable
> wm protocol . WM_DELETE_WINDOW what_to_do_on_close
> but that does not get invoked when you do [destroy .]
> programmatically, so that's not enough. I tried
> package forget Tk
> and various other things, but...
> any hints welcomed!
See Tk Feature Request 456548.
This is a legacy from the days when Tk could only be found in
wish. This part of Tk still assumes it's in wish, and when all
windows go away, wish exits, so all Tk commands are disabled.
One possible workaround would be to [load] Tk in a slave interp.
Then when it's made dead in one, you can [load] Tk again in a new
slave interp to get going again.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Jonathan Bromley
>See Tk Feature Request 456548.
>
>This is a legacy from the days when Tk could only be found in
>wish. This part of Tk still assumes it's in wish, and when all
>windows go away, wish exits, so all Tk commands are disabled.
>
>One possible workaround would be to [load] Tk in a slave interp.
>Then when it's made dead in one, you can [load] Tk again in a new
>slave interp to get going again.
Thanks!
For now, I'll probably stick with some WM_DELETE_WINDOW hokum
to avoid the worst problems.
dkf
> One possible workaround would be to [load] Tk in a slave interp.
> Then when it's made dead in one, you can [load] Tk again in a new
> slave interp to get going again.
The other workaround is to withdraw the "." window and only let the
user close its children. That works pretty well in my experience, and
is something I'd recommend for all complex applications. (It can also
make working with widget pathnames easier in practice...)
Donal.
Arjen Markus
Right: all widget pathnames then have a parent of the form ".widget",
whereas the children of "." have or seem to have a parent of the form
"".
Regards,
Arjen
Georgios Petasis
You may have problems with some dialogs though :-)
George
Robert Heller
Not if you are careful to *always* use the -parent option available for
all of the tk_<mumble> functions.
>
> George
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
hel...@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
Georgios Petasis
>>> On 10 June, 18:36, Don Porter <d...@nist.gov> wrote:
>>>> One possible workaround would be to [load] Tk in a slave interp.
>>>> Then when it's made dead in one, you can [load] Tk again in a new
>>>> slave interp to get going again.
>>> The other workaround is to withdraw the "." window and only let the
>>> user close its children. That works pretty well in my experience, and
>>> is something I'd recommend for all complex applications. (It can also
>>> make working with widget pathnames easier in practice...)
>>>
>>> Donal.
>> You may have problems with some dialogs though :-)
>
> Not if you are careful to *always* use the -parent option available for
> all of the tk_<mumble> functions.
Or wrap the dialogs into other procs, that set -parent to the window
that has the focus... (This is what I usually prefer...)
But it is a tricky point with this approach.
The other approach is to set the "." geometry to 1x1, remove the window
bar, and place it just 1 pixel outside the visible desktop. With this
approach "." is visible, so no problem (I think :-) )...
George
Gerhard Reithofer
> O/H Robert Heller ??????:
> > At Thu, 11 Jun 2009 14:01:12 +0300 Georgios Petasis
> > <pet...@iit.demokritos.gr> wrote:
> >
> > > O/H dkf ??????:
> > > > On 10 June, 18:36, Don Porter <d...@nist.gov> wrote:
> > > > > One possible workaround would be to [load] Tk in a slave interp.
> > > > > Then when it's made dead in one, you can [load] Tk again in a new
> > > > > slave interp to get going again.
> > > > The other workaround is to withdraw the "." window and only let the
> > > > user close its children. That works pretty well in my experience, and
> > > > is something I'd recommend for all complex applications. (It can also
> > > > make working with widget pathnames easier in practice...)
> > > >
> > > > Donal.
> > > You may have problems with some dialogs though :-)
> >
> > Not if you are careful to *always* use the -parent option available for
> > all of the tk_<mumble> functions.
>
> Or wrap the dialogs into other procs, that set -parent to the window that has
...
Back after 2 weeks.
THX to all.