On Aug 26, 2006, at 6:31 AM, Neil Hughes wrote:
> I'm still building Windows EXEs via the Mcmillan installer that I
> set-up
> quite a while ago (I'll get standaloneBuilder one of these days!)
> and I
> still use that old debugging technique, the print statement, all
> the time.
>
> For some reason I had assumed that switching the standalone config
> file
> from console to no-console would make no difference if I left the
> print
> statements in place, i.e. the standard output would just get
> directed to
> NULL or something. However I just tracked down a problem I was
> having to
> the fact that with the console switched off but the printing still
> active my PythonCard app was stopping halfway through processing a
> button press and control returning to the event loop. The issue would
> not affect every PC the application was running on but when it
> happened
> it was always in the same place.
>
> I presume printing to no console is therefore "a bad thing" and the
> standalone build mechanism isn't capable of redirecting standard
> output
> with no console - could anyone confirm this?
>
> It also makes me wonder what happens to standard error output, e.g.
> exceptions. Traditionally they get reported to the console - in
> "non-console mode" could this also trigger issues (presumably in most
> cases the exception occurring in the first place is probably a bad
> sign,
> but sometimes you might be able to recover)? Do I need to make sure
> that
> any error output is blocked off as well or logged to a file?
>
> I feel a bit of an idiot for taking so long to realize what now seems
> pretty obvious, but I just wanted to make sure I am now correct and
> that
> there isn't something else weird going on with my application and this
> standard output business is just a red herring.
>
> --
> Neil Hughes
>
That sounds more like a bug in McMillan to me. Have you tried using
the updated pyInstaller instead? Maybe it is changing where
sys.stdout and sys.stderr go? You could add some fields to your
application and dump the values for both of those. You could also
assign some other file-like object to sys.stdout. You could make your
own that even dumps text on a write to a hidden TextArea field which
might be a temporary workaround until you figure out the real
problem. Alternatively, assign a real file handle to sys.stdout or
sys.stderr and capture the specific tracebacks that way. Just a few
ideas to help debug the problem.
ka
|
