Re: [Pythoncard-users] Cleaning up when closing pythoncard applications

[Kevin A. <al...@se...>]

On Sep 10, 2004, at 11:06 AM, Tim Black wrote:

> I just solved a problem I was having with a py2exe windows standalone
> whereby the windows process never terminated after closing the app. As
> you might suspect, this involved a thread in my app that didn't
> terminate gracefully. I found in the PythonCard samples several 
> examples
> of using threads and in each case, the thread's daemon flag was set to 
> 1
> to make it daemonic so that it is cleaned up when the non-daemonic
> thread (my Main GUI thread) exits. This solved my problem. However,
> until I found this solution, I was trying another solution. Let's
> pretend for a second that thread.setDaemon wouldn't work and we have to
> make my secondary thread explicitly "killable" by having its run
> function do:
>
> def run(self):
> 	while self._running:
> 		# do stuff
> 		pass
>
> and its stop func do:
>
> def stop(self):
> 	self._running = False
>
> so that my Pythoncard app can call this thread's stop function to
> explicitly kill it. But where and when should this be called? I can
> handle the reqests to close the app via a file menu exit callback, but
> what about for "X"ing the application or other sorts of ungraceful
> termination? I see that self.Close() gets called. I guess what I am
> asking is what is EVT_CLOSE bound to? Where can I place cleanup
> statements like thread stopping, etc?
>
> Thanks,
> Tim
>

EVT_CLOSE is bound to on_close, just remember to call event.skip() if 
you want to have the close event passed on, otherwise your app won't be 
killable except via the process manager, etc. The examples you were 
looking at should have been using on_close already. The background 
events are bound in model.py and include: activate, close, deactivate, 
idle, initialize, maximize, minimize, move, restore, and size. restore 
is the inverse of minimize.

ka