[PyQt] No errors reported by deployed application, no functionality either

Barry Scott barry at barrys-emacs.org
Fri Mar 25 19:32:45 GMT 2016

On Thursday 24 March 2016 17:00:58 Kyle Altendorf wrote:
> On 2016-02-07 15:02, Kyle Altendorf wrote:
> > On 2016-02-06 19:57, michael h wrote:
> >> Have you tried something like:
> >> 
> >> myapp.exe > out.txt 2>&1
> >> 
> >> from cmd?
> > 
> > Very interesting.  That did help it out and the expected messages
> > showed up in `out.txt`.  I tried checking all encodings in pyqtdeploy
> > (except the Japanese that seemed to not be present in my Python
> > install) but that didn't help.  I had previously added cp1252 (IIRC)
> > when that was complained about being missing while running from within
> > pyqtdeploy.
> > 
> > So, with this ability to see the messages I was able to get a messy
> > but functional .pdy file that creates a `result` directory I can copy
> > to a clean virtual machine and run.  Well, I did have to install
> > drivers for my CAN adapter, but that's expected.  Thanks so much for
> > the help.  I guess I have to continue digging into what is wrong with
> > stdout.  Perhaps it is a Win10 issue?  At least it is recreatable and
> > without pyqtdeploy or PyQt at all, I think.  This exact command prints
> > in Cygwin but exits silently and with a 0 exit code (%errorlevel%) in
> > cmd.exe.  Redirecting does not help in this case though, so maybe not
> > quite the same.
> > 
> > "c:/python34/python" -c 'print("blue")'
> Aside from the apparent quoting error in this line and it's total lack
> of relationship to my problem...  I did figure out and fix [1] my
> underlying issue.
> My issue was introduced when I was initially getting pyqtdeploy working
> because I added sys.stdout.Flush() as a diagnostic attempt when no
> messages were printed to the screen and then did not remove it after
> solving those other issues.  The result at first was that when the
> application was deployed as a GUI, sys.stdout was None and hence an
> exception was thrown.  Without any stdout, the exception had nowhere to
> be reported.  Later I added the GUI exception dialog but
> sys.stdout.flush() was called before I created my QApplication() so
> another exception was thrown when I attempted to launch the
> QMessageBox() to report the first exception.  But, it seems to all be
> unwound now.
> I'm not sure but this may relate in some way to Python issue #17797 [2].
> As always, thanks for the help.  I would say that I hope this will help
> someone else but I bet there aren't too many out there pointlessly
> flushing sys.stdout in their GUI applications...

I find that it is very important to take control of sys.stdout and sys.stderr
 in a GUI program. I push any output seen into my apps log file so that
users can report issues that come up (and I can see them in development).


> Cheers,
> -kyle
> [1]
> https://github.com/altendky/st/commit/fda167f20081ba0f24293d71535b68b2e6954b
> b0 [2]
> https://riverbankcomputing.com/pipermail/pyqt/2015-January/035442.html
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt

More information about the PyQt mailing list