Stian wrote:
On Windows, by default, scripts with a .py extension are run by
Python.exe, which is a console application. If you can write to stdout
and see the results in a console window, then you have a console.
Scripts with a .pyw extension are run by Pythonw.exe, which is a Windows
application. Those scripts do not have a console. If your installer is
embedding pythonw.exe as the executioner, then that's probably what
you're using.
Thanks for enlightening me :)
Does this make it any clearer what may be wrong?
No. ;) I don't see anything immediately obvious. If it were me, I'd
write a tiny C application to try the exact same APIs to kill your
console app, just to make sure that the sequence does work as expected.
Print out the "pid", then pass that to the C app by hand. Remember to
make it a Windows app (WinMain instead of main) so that you don't get
your own console.
First; my wxPython GUI application is basically used to configure and
start/stop the console application. Here is what I did now:
I start the GUI application and do a too quick stop - making the
win32console come into this concurring failing state. Then I start another
instance of the same GUI app. This detects the running console
application,
and I hit the "stop"-button in this new instance. It then attaches to the
console and terminates it without problems.
If I now start the console application again I am able to stop it without
problems from the new instance of the GUI, but with the old instance I
still
get the same error each time...
So, basically the win32console gets into a failing state when it gets the
"Handler is invalid." exception, and it doesn't get out of this state even
if I call FreeConsole(). So the question is how to clean up this mess. Is
there another function I can call? Can I reinitialize the win32console
somehow? Create a new instance or get a clean start in some other way..? I
feel like this was a silly question, but I'm in the blue here...
Thanks!
Stian
I've seen this myself, but couldn't reliably reproduce it.
If I recall, allocating a new console, and then immediately
freeing it seemed to clear the 'in-between' state.
Roger
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
