How Does One Avoid Killing a Dead Window?

Tom15 · August 19, 2010, 6:59pm

I do something like the following every time I create a new top window
(I use them to display files without the user having to close them
before doing more actions in the main program [non-modal, I believe]):

topwin = LogTextFrame(logfilename, text)
self.winlist.append(topwin)

Later, I want to close all windows that haven't been closed:

  for w in self.winlist: # does any touch of a dead object here throw
an exception?
      # how to test w for a viable object?
      w.Close()

But I get an exception somewhere I can't seem to trap:

<mypkg.logtextframe.LogTextFrame; proxy of <Swig Object of type
'wxFrame *' at 0x324cc00> >

Is there any reliable way to test a handle to an object to see if it
is dead or alive?

Thanks.

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA

Cody · August 19, 2010, 7:02pm

Hi,

I do something like the following every time I create a new top window
(I use them to display files without the user having to close them
before doing more actions in the main program [non-modal, I believe]):

topwin = LogTextFrame(logfilename, text)
self.winlist.append(topwin)

Later, I want to close all windows that haven't been closed:

for w in self.winlist: # does any touch of a dead object here throw
an exception?
# how to test w for a viable object?
w.Close()

But I get an exception somewhere I can't seem to trap:

<mypkg.logtextframe.LogTextFrame; proxy of <Swig Object of type
'wxFrame *' at 0x324cc00> >

Is there any reliable way to test a handle to an object to see if it
is dead or alive?

I assume your getting a PyDeadObjectError exception?

for w in self.winlist:
if w:
w.Close()

OR

for w in self.winlist:
    try:
        w.Close()
    except wx.PyDeadObjectError:
        pass

Cody

···

On Thu, Aug 19, 2010 at 1:59 PM, Tom Browder <tom.browder@gmail.com> wrote:

Tom15 · August 19, 2010, 9:00pm

But I get an exception somewhere I can't seem to trap:

Note the exception (but is it an exception?) I do get:

<mypkg.logtextframe.LogTextFrame; proxy of <Swig Object of type
'wxFrame *' at 0x324cc00> >

I assume your [sic] getting a PyDeadObjectError exception?

for w in self.winlist:
if w:
w.Close()

That doesn't work for some reason--I thing it's because w is an address.

OR

for w in self.winlist:
try:
w.Close()
except wx.PyDeadObjectError:
pass

I can't catch that exception!

Does anyone know more about what a proxy is in wxPython terms? Are
thee attributs od methods for it? Does it ever become zero?

Thanks, Cody.

-Tom

···

On Thu, Aug 19, 2010 at 14:02, Cody Precord <codyprecord@gmail.com> wrote:

Andrea_Gavana · August 19, 2010, 9:03pm

Hi Tom,

But I get an exception somewhere I can’t seem to trap:

Note the exception (but is it an exception?) I do get:

<mypkg.logtextframe.LogTextFrame; proxy of <Swig Object of type

‘wxFrame *’ at 0x324cc00> >

This is not an exception: it appears to me the window is still pretty alive.

I assume your [sic] getting a PyDeadObjectError exception?

for w in self.winlist:

if w:
   w.Close()
That doesn’t work for some reason–I thing it’s because w is an address.

OR

for w in self.winlist:

try:
   w.Close()
except wx.PyDeadObjectError:
   pass
I can’t catch that exception!

Does anyone know more about what a proxy is in wxPython terms? Are

thee attributs od methods for it? Does it ever become zero?

Can you try with something like this:

for w in self.winlist:

if w.IsBeingDeleted():

continue

w.Close() # or w.Destroy()

?

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”
http://xoomer.alice.it/infinity77/

==> Never EVER use RemovalGroup for your house removal. You’ll regret it forever.

http://thedoomedcity.blogspot.com/2010/03/removal-group-nightmare.html <==

···

On 20 August 2010 00:00, Tom Browder wrote:

On Thu, Aug 19, 2010 at 14:02, Cody Precord codyprecord@gmail.com wrote:

Cody · August 19, 2010, 9:06pm

Hi,

But I get an exception somewhere I can't seem to trap:

Note the exception (but is it an exception?) I do get:

<mypkg.logtextframe.LogTextFrame; proxy of <Swig Object of type
'wxFrame *' at 0x324cc00> >

This is not an exception, where is the rest of the call stack?

I can't catch that exception!

Does anyone know more about what a proxy is in wxPython terms? Are
thee attributs od methods for it? Does it ever become zero?

This is irrelevant to the issue your (seem) to be describing. When
your Frame's are closed do you call Destroy on them? If not then they
will not be garbage collected because you are still holding a
reference to them in your list.

If your getting a crash that is caused by an exception please post the
exceptions traceback.

Cody

···

On Thu, Aug 19, 2010 at 4:00 PM, Tom Browder <tom.browder@gmail.com> wrote:

On Thu, Aug 19, 2010 at 14:02, Cody Precord <codyprecord@gmail.com> wrote:

Tom15 · August 19, 2010, 9:30pm

...

This is not an exception: it appears to me the window is still pretty alive.

...

Can you try with something like this:
for w in self.winlist:
if w.IsBeingDeleted():
continue
w.Close() # or w.Destroy()
?

Andrea, I tried with both Close and Destroy and it didn't work.

Thanks,

-Tom

···

On Thu, Aug 19, 2010 at 16:03, Andrea Gavana <andrea.gavana@gmail.com> wrote:

Tom15 · August 19, 2010, 9:33pm

...

<mypkg.logtextframe.LogTextFrame; proxy of <Swig Object of type
'wxFrame *' at 0x324cc00> >

This is not an exception, where is the rest of the call stack?

I haven't been able to get it yet--just starting to learn how to do
in-depth debugging.

Thanks, Cody.

-Tom

···

On Thu, Aug 19, 2010 at 16:06, Cody Precord <codyprecord@gmail.com> wrote:

Robin · August 19, 2010, 9:48pm

But I get an exception somewhere I can't seem to trap:

Note the exception (but is it an exception?) I do get:

<mypkg.logtextframe.LogTextFrame; proxy of<Swig Object of type
'wxFrame *' at 0x324cc00> >

I assume your [sic] getting a PyDeadObjectError exception?

for w in self.winlist:
    if w:
        w.Close()

That doesn't work for some reason--I thing it's because w is an address.

OR

for w in self.winlist:
    try:
        w.Close()
    except wx.PyDeadObjectError:
        pass

I can't catch that exception!

Please make a small runnable sample that demonstrates the problem. MakingSampleApps - wxPyWiki

Does anyone know more about what a proxy is in wxPython terms? Are
thee attributs od methods for it? Does it ever become zero?

A proxy is simply a Python face in front of a C++ object.

···

On 8/19/10 2:00 PM, Tom Browder wrote:

On Thu, Aug 19, 2010 at 14:02, Cody Precord<codyprecord@gmail.com> wrote:

--
Robin Dunn
Software Craftsman

Tom15 · August 19, 2010, 9:55pm

...

Please make a small runnable sample that demonstrates the problem.
MakingSampleApps - wxPyWiki

Will do.

Thanks, Robin.

-Tom

···

On Thu, Aug 19, 2010 at 16:48, Robin Dunn <robin@alldunn.com> wrote:

On 8/19/10 2:00 PM, Tom Browder wrote:

Robin · August 19, 2010, 9:56pm

BTW, there are a couple things that you may not be aware of that could make it unnecessary for you to do this.

1. If you make the other frames be children of your main frame then they will all be closed automatically when the main frame closes.

2. wx already has a list of all top level windows, so if #1 is not a good fit for you then you can do something like this to close all windows:

for w in wx.GetTopLevelWindows():
w.Close()

···

On 8/19/10 11:59 AM, Tom Browder wrote:

I do something like the following every time I create a new top window
(I use them to display files without the user having to close them
before doing more actions in the main program [non-modal, I believe]):

topwin = LogTextFrame(logfilename, text)
self.winlist.append(topwin)

--
Robin Dunn
Software Craftsman

Tom15 · August 19, 2010, 10:22pm

I do something like the following every time I create a new top window
(I use them to display files without the user having to close them
before doing more actions in the main program [non-modal, I believe]):

topwin = LogTextFrame(logfilename, text)
self.winlist.append(topwin)

BTW, there are a couple things that you may not be aware of that could make
it unnecessary for you to do this.

1. If you make the other frames be children of your main frame then they
will all be closed automatically when the main frame closes.

2. wx already has a list of all top level windows, so if #1 is not a good
fit for you then you can do something like this to close all windows:
   for w in wx\.GetTopLevelWindows\(\):
           w\.Close\(\)

That worked!

Actually, I want to kill al top level windows EXCEPT the first (main)
so I tried

def KillTopWins(self, evt)

for w in wx.GetTopLevelWindows():
w.Close()

···

On Thu, Aug 19, 2010 at 16:56, Robin Dunn <robin@alldunn.com> wrote:

On 8/19/10 11:59 AM, Tom Browder wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Tom15 · August 19, 2010, 10:29pm

Please forgive my last, incomplete message--finger fuddle and premature send.
...

BTW, there are a couple things that you may not be aware of that could make
it unnecessary for you to do this.

...

2. wx already has a list of all top level windows, so if #1 is not a good
fit for you then you can do something like this to close all windows:
   for w in wx\.GetTopLevelWindows\(\):
           w\.Close\(\)

That worked! But since I want to close all top windows execept the
main one I did this in a function called by the mani top window:

  def KillTopWins(self):
       for w in wx.GetTopLevelWindows():
             if w == self:
                  continue
             w.Close()

Thanks, Robin!

-Tom

···

On Thu, Aug 19, 2010 at 16:56, Robin Dunn <robin@alldunn.com> wrote:

Dev_Player · August 20, 2010, 4:02pm

Just curious Tom,

Originally did the frame that was giving your a problem have a
wx.Timer object in it that wasn't mytimer.Stop()'d,
or did you have a process or thread holding a reference to some object
in a window you were trying to close?

Tom15 · August 20, 2010, 4:53pm

No, no timer. What I had was several top-level windows in addition to
the main one, each generated to hold stderr and stdout from a
subprocess. Each subprocess wrote its own stdout/stderr to two files
which the main process read (and then closed) and showed the text in
two top-level windows. Note that each subprocess uses the same file
names, but no two subprocesses can run or write files at the same
time.

Top-level windows accumulate from each subprocess and I allow the user
at any time to kill all the non-main top-level windows if desired
without killing the main window.

I probably don't have a clean solution for how to handle that (I get
very confused reading the subprocess module docs), but Robin's
solution did the trick.

Eventually I would like to show the set up in a short demo program for
advice on best practices, but I have to press on now with using my app
as it is.

Regards,

-Tom

···

On Fri, Aug 20, 2010 at 11:02, DevPlayer <devplayer@gmail.com> wrote:

Just curious Tom,

Originally did the frame that was giving your a problem have a
wx.Timer object in it that wasn't mytimer.Stop()'d,
or did you have a process or thread holding a reference to some object
in a window you were trying to close?

Dev_Player · August 20, 2010, 10:42pm

I've only barely dabbled in thread coding but I think I've seen others
use Queues for inter thread communication.

Personally, I'd use one thread for each particular limited system
resource or a specific file and that thread talk to other threads
through a read Queue and a write queue. In other words have a
File_thread for reading and writing to a file and post to the Queue on
the reads and popping from the Queue on writes to the file. Other
threads would pop to read from the queue and post to the queue to
write to it. Of course this style is more an event like use of threads
then a multitasking construct.

Using the same idea of one thread controlling the file, perhaps take a
look at pubsub too instead of reading and writing to a queue.

If anyone feels I'm misdirecting OP Tom, let us know, so I may learn
too.

···

On Aug 20, 12:53 pm, Tom Browder <tom.brow...@gmail.com> wrote:

On Fri, Aug 20, 2010 at 11:02, DevPlayer <devpla...@gmail.com> wrote:
> Just curious Tom,

> Originally did the frame that was giving your a problem have a
> wx.Timer object in it that wasn't mytimer.Stop()'d,
> or did you have a process or thread holding a reference to some object
> in a window you were trying to close?

No, no timer. What I had was several top-level windows in addition to
the main one, each generated to hold stderr and stdout from a
subprocess. Each subprocess wrote its own stdout/stderr to two files
which the main process read (and then closed) and showed the text in
two top-level windows. Note that each subprocess uses the same file
names, but no two subprocesses can run or write files at the same
time.

Top-level windows accumulate from each subprocess and I allow the user
at any time to kill all the non-main top-level windows if desired
without killing the main window.

I probably don't have a clean solution for how to handle that (I get
very confused reading the subprocess module docs), but Robin's
solution did the trick.

Eventually I would like to show the set up in a short demo program for
advice on best practices, but I have to press on now with using my app
as it is.

Regards,

-Tom

Tom15 · August 20, 2010, 11:37pm

I've only barely dabbled in thread coding but I think I've seen others
use Queues for inter thread communication.
Personally, I'd use one thread for each particular limited system
resource or a specific file and that thread talk to other threads
through a read Queue and a write queue. In other words have a
File_thread for reading and writing to a file and post to the Queue on

Well, I'm not convinced yet that I use more than the main thread plus
one thread for the current subprocess.

Using the same idea of one thread controlling the file, perhaps take a
look at pubsub too instead of reading and writing to a queue.

I have used pubsub but I'm not sure it's needed here.

I guess I need to do some serious debugging to determine what's really
happening.

Thanks, DevPlayer

Regards,

-Tom

···

On Fri, Aug 20, 2010 at 17:42, DevPlayer <devplayer@gmail.com> wrote: