stdout/stderr is preventing my app from closing - how do I destroy it?

hey

I have the issue that when I close the last window of my app, it will
not terminate if stdout/stderr had ever previously been called. For
example, if I ever use 'print' in the app (not that I want to in the
final version, but the point stands), then the stdout/stderr window
will remain open until the user closes that as well.

Overriding the EVT_CLOSE handler and calling self.Destroy() on the
main window doesn't help, and attempting wx.Exit() in the handler
hangs the app.

This applies regardless of whether I pass redirect=False to the app or
not.

The issue is that I want to run the final product from a .pyw file;
and the fact that stdout/stderr is not terminating correctly is
causing the process to hang if I run it as such and then close the
main window.

How can I close the stdout/stderr window in the EVT_CLOSE handler, and
thus terminate the application? Or, perhaps more relevantly, is there
a better way to handle this?

I'm running Windows 7 64 bit, python 2.6.4, wxpython 2.8.10.1 32-bit.
Everything else to do with wxpython runs perfectly, so I doubt it's
any sort of hardware issue (but I figure it can't hurt to mention it).

I can write up some code to demonstrate this if required, but I can't
provide the in-place copy because it's several thousand lines all up.

Thanks in advance for your help :slight_smile:

···

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

Hi,

···

On Apr 20, 6:13 am, sapi <sean.pur...@gmail.com> wrote:

hey

I have the issue that when I close the last window of my app, it will
not terminate if stdout/stderr had ever previously been called. For
example, if I ever use 'print' in the app (not that I want to in the
final version, but the point stands), then the stdout/stderr window
will remain open until the user closes that as well.

Overriding the EVT_CLOSE handler and calling self.Destroy() on the
main window doesn't help, and attempting wx.Exit() in the handler
hangs the app.

This applies regardless of whether I pass redirect=False to the app or
not.

The issue is that I want to run the final product from a .pyw file;
and the fact that stdout/stderr is not terminating correctly is
causing the process to hang if I run it as such and then close the
main window.

How can I close the stdout/stderr window in the EVT_CLOSE handler, and
thus terminate the application? Or, perhaps more relevantly, is there
a better way to handle this?

I'm running Windows 7 64 bit, python 2.6.4, wxpython 2.8.10.1 32-bit.
Everything else to do with wxpython runs perfectly, so I doubt it's
any sort of hardware issue (but I figure it can't hurt to mention it).

I can write up some code to demonstrate this if required, but I can't
provide the in-place copy because it's several thousand lines all up.

Thanks in advance for your help :slight_smile:

I assume you're talking about the automated stdout window that is
created when you pass the App object's redirect=True. If so, then I've
never seen a way to close that thing programmatically...but passing
False should keep that window from even being displayed. I usually
don't use it, but I do use "prints" just fine and my programs all
close just fine too. Having a simple demo would definitely help.

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

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

hey

I have the issue that when I close the last window of my app, it will
not terminate if stdout/stderr had ever previously been called. For
example, if I ever use 'print' in the app (not that I want to in the
final version, but the point stands), then the stdout/stderr window
will remain open until the user closes that as well.

Overriding the EVT_CLOSE handler and calling self.Destroy() on the
main window doesn't help, and attempting wx.Exit() in the handler
hangs the app.

This applies regardless of whether I pass redirect=False to the app or
not.

You really still get the stdio window when passing False? That should not happen and if it is then you've likely got some other problem going on and I'd like to see a sample that reproduces this issue.

The issue is that I want to run the final product from a .pyw file;
and the fact that stdout/stderr is not terminating correctly is
causing the process to hang if I run it as such and then close the
main window.

How can I close the stdout/stderr window in the EVT_CLOSE handler, and
thus terminate the application? Or, perhaps more relevantly, is there
a better way to handle this?

Use the source Luke! :wink: wx.App will have a stdioWin attribute when the stdio window has been created, so you should be able to do something like this:

  app = wx.GetApp()
  if hasattr(app, 'stdioWin') and app.stdioWin:
    app.stdioWin.Close()
    app.RestoreStdio()

···

On 4/20/10 4:13 AM, sapi wrote:

--
Robin Dunn
Software Craftsman

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

> hey

> I have the issue that when I close the last window of my app, it will
> not terminate if stdout/stderr had ever previously been called. For
> example, if I ever use 'print' in the app (not that I want to in the
> final version, but the point stands), then the stdout/stderr window
> will remain open until the user closes that as well.

> Overriding the EVT_CLOSE handler and calling self.Destroy() on the
> main window doesn't help, and attempting wx.Exit() in the handler
> hangs the app.

> This applies regardless of whether I pass redirect=False to the app or
> not.

You really still get the stdio window when passing False? That should
not happen and if it is then you've likely got some other problem going
on and I'd like to see a sample that reproduces this issue.

Well, it's not that I still get the stdio window, but it was still
hanging on the console (where stdio goes when passing False).

> The issue is that I want to run the final product from a .pyw file;
> and the fact that stdout/stderr is not terminating correctly is
> causing the process to hang if I run it as such and then close the
> main window.

> How can I close the stdout/stderr window in the EVT_CLOSE handler, and
> thus terminate the application? Or, perhaps more relevantly, is there
> a better way to handle this?

Use the source Luke! :wink: wx.App will have a stdioWin attribute when the
stdio window has been created, so you should be able to do something
like this:

    app = wx\.GetApp\(\)
    if hasattr\(app, &#39;stdioWin&#39;\) and app\.stdioWin:
            app\.stdioWin\.Close\(\)
            app\.RestoreStdio\(\)

Thanks - that worked (although weirdly it's .close() not .Close(),
which seems a bit inconsistent).

What's the purpose of calling RestoreStdio() if the window is going to
be destroyed anyway, out of interest?

@ Mike - I was going to provide a sample, but after Robin's suggestion
the window closes correctly. I'm using threading a fair bit, though,
and that's still hanging the app on close. The trial app I did up
didn't have that problem (I could close the thread by sending '/KILL/'
as a string, which is how I wanted it) but the main one still does, so
I assume that I've somehow lost track of a thread and aren't killing
it properly.

I'll have a look at that later today, but it's worth asking - does
anyone know of a way to instantly terminate all sub-processes created
via threading?

Thanks again!

···

On Apr 21, 5:34 am, Robin Dunn <ro...@alldunn.com> wrote:

On 4/20/10 4:13 AM, sapi wrote:

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

hey

I have the issue that when I close the last window of my app, it will
not terminate if stdout/stderr had ever previously been called. For
example, if I ever use 'print' in the app (not that I want to in the
final version, but the point stands), then the stdout/stderr window
will remain open until the user closes that as well.

Overriding the EVT_CLOSE handler and calling self.Destroy() on the
main window doesn't help, and attempting wx.Exit() in the handler
hangs the app.

This applies regardless of whether I pass redirect=False to the app or
not.

You really still get the stdio window when passing False? That should
not happen and if it is then you've likely got some other problem going
on and I'd like to see a sample that reproduces this issue.

Well, it's not that I still get the stdio window, but it was still
hanging on the console (where stdio goes when passing False).

Then you probably have some other top-level window that still exists. Check your dialogs.

Use the source Luke! :wink: wx.App will have a stdioWin attribute when the
stdio window has been created, so you should be able to do something
like this:

         app = wx.GetApp()
         if hasattr(app, 'stdioWin') and app.stdioWin:
                 app.stdioWin.Close()
                 app.RestoreStdio()

Thanks - that worked (although weirdly it's .close() not .Close(),
which seems a bit inconsistent).

Right, self.stdioWin is actually a file-like object that does the redirecting of the output to the window, so close() is a file-like close method.

What's the purpose of calling RestoreStdio() if the window is going to
be destroyed anyway, out of interest?

To reset sys.stdout and sys.stderr to the original files in case there is any other output after you've closed the window.

···

On 4/20/10 3:25 PM, sapi wrote:

On Apr 21, 5:34 am, Robin Dunn<ro...@alldunn.com> wrote:

On 4/20/10 4:13 AM, sapi wrote:

--
Robin Dunn
Software Craftsman

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

>>> hey

>>> I have the issue that when I close the last window of my app, it will
>>> not terminate if stdout/stderr had ever previously been called. For
>>> example, if I ever use 'print' in the app (not that I want to in the
>>> final version, but the point stands), then the stdout/stderr window
>>> will remain open until the user closes that as well.

>>> Overriding the EVT_CLOSE handler and calling self.Destroy() on the
>>> main window doesn't help, and attempting wx.Exit() in the handler
>>> hangs the app.

>>> This applies regardless of whether I pass redirect=False to the app or
>>> not.

>> You really still get the stdio window when passing False? That should
>> not happen and if it is then you've likely got some other problem going
>> on and I'd like to see a sample that reproduces this issue.

> Well, it's not that I still get the stdio window, but it was still
> hanging on the console (where stdio goes when passing False).

Then you probably have some other top-level window that still exists.
Check your dialogs.

>> Use the source Luke! :wink: wx.App will have a stdioWin attribute when the
>> stdio window has been created, so you should be able to do something
>> like this:

>> app = wx.GetApp()
>> if hasattr(app, 'stdioWin') and app.stdioWin:
>> app.stdioWin.Close()
>> app.RestoreStdio()
> Thanks - that worked (although weirdly it's .close() not .Close(),
> which seems a bit inconsistent).

Right, self.stdioWin is actually a file-like object that does the
redirecting of the output to the window, so close() is a file-like close
method.

Got it, that makes sense.

> What's the purpose of calling RestoreStdio() if the window is going to
> be destroyed anyway, out of interest?

To reset sys.stdout and sys.stderr to the original files in case there
is any other output after you've closed the window.

Does this reset the value of redirect as well?

(I sorted out what the problem was, incidentally. The threads I was
trying to kill were network threads, so I was sending a packet to the
local ip that was just '/KILL/', which would cause the thread to break
the listen loop. The problem was that before doing so, the thread was
calling up to the parent window and attempting to display a status
message - and what I missed, but is in retrospect obvious, is that you
can't make any calls to a wx.Window/wx.Frame when it's in its
EVT_CLOSE handler. Does that sound about right?)

···

On Apr 21, 8:32 am, Robin Dunn <ro...@alldunn.com> wrote:

On 4/20/10 3:25 PM, sapi wrote:
> On Apr 21, 5:34 am, Robin Dunn<ro...@alldunn.com> wrote:
>> On 4/20/10 4:13 AM, sapi wrote:
--
Robin Dunn
Software Craftsmanhttp://wxPython.org

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

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