Tkinter protocol("WM_DELETE_WINDOW,...)

[Dave Hansen]

Thanks for your response,

On 08 May 2003 12:01:31 -0700, Chad Netzer <cnetzer at mail.arc.nasa.gov>
wrote:

>On Thu, 2003-05-08 at 08:43, Dave Hansen wrote:
[...]
>> The Tkinter script keeps the same basic structure.  There are many
>> kinds of nodes, but they basically all look something like this:
>> 
>>    class Node(Frame):
>>       def __init__(self, <question, answers, results>):
>>          <Build the node.  No Tkinter calls>
>
>Why to you derive Node from Frame?  You are saying that each Node is-a

Because some example code I looked at did so, and I followed suit.  As
you suggest, I could instead add a self.frame member.  But if I did
that, I don't think it will change anything.

[...]
>
>>       def ask(self):
>>          Frame.__init__(self)
>>          <Build and pack a frame for the user>
>
>Again, if you end up doing a "self.pack()" anywhere in here, you are
>certainly doing things in an odd manner (I won't go so far as to say
>'wrong', but in my experience, such things always, always, ALWAYS lead
>to problems.

Yes, I do a self.pack (along with packing several other subframes).
But there don't seem to be any problems in geometry management.

>
>>          self.result = Terminate        # Special flag
>>          self.wait_window(self)
>
>if each Node had a 'self.frame=Frame()', then you could do
>'self.frame.wait_window()'

ITYM self.frame.wait_window(self.frame).  Otherwise I believe it's
waiting for the root Toplevel.

>
>
>> Also note that no call to mainloop is made.  This is due to the way
>> the script eveolved (text mode => Tkinter).
>
>Bingo.  If you aren't running mainloop(), and you are still relying on
>events to occur (window events, window manager events, etc.) then you
>better have a REALLY good idea of how event processing works in Tkinter
>(because you will have to do it yourself, using lots of update() calls)

I thought that might be part of it, which is why I mentioned it. 

However, there are no other windows active other than the root
Toplevel, and wait_window does process window events.  And I only have
one call to update, the one I mentioned in my previous post.  

I believe that call to update is necessary (in my code) because
closing the root Toplevel affects something that's not part of the
frame we're waiting for.  I'm thinking the call to update allows my
window to finish processing its events before the root Toplevel gets
destroyed.

>
>The simple answer to this is, "Use mainloop()".  A lot of your problems
>will magically disappear.

Actually, I don't have any problems right now.  The application works
well.  I think I know what was happening, and I think I fixed it.

But I don't usually do GUI stuff.  I make my living writing software
for embedded microcontrollers.  I was just looking for other
perspectives.  And I do appreciate your response.

FWIW, I started out with the ask method calling mainloop rather than
wait_window, and the process method calling quit rather than destroy.
But that seemed heavy-handed, and I ran into some problems (that I
can't recall at the moment).  Substituting wait_window and destroy
simplified some things and made it work better.

I do have some ideas for restructuring the code to use mainloop, and
I'll probably get around to that sooner or later.  But my main
objective with this post is to learn if I'm really understanding
what's going on, or just (un)lucky.

Thanks again,

                               -=Dave
-- 
Change is inevitable, progress is not.