I used this code attached to a toolbar button to launch my help filie:
try:
os.spawnvp(os.P_WAIT, 'kchmviewer', ['kchviewer', filename] )
except:
pass
Runs the help ok, but then my program interface 'hang's, ie the help program
is still attatched to my gui. If I close the help, my gui comes back. If I
click on the task bar to get back my gui, my gui is just an unresponsive
blurred mess.
Any ideas?
richard
Calling os.spawn*() with os.P_WAIT will result in the thread that called
the function to stall waiting for the created process to finish, as per
the documentation. There are many ways around this;
* Wrap the above into a new thread.
* Use os.P_NOWAIT instead.
* Use the subprocess module (built in with Python 2.4 and later).
* Use the wx.Execute/wx.Process pair.
Etcetera.
- Josiah
Richard Terry <rterry@internode.on.net> wrote:
I used this code attached to a toolbar button to launch my help filie:
try:
os.spawnvp(os.P_WAIT, 'kchmviewer', ['kchviewer', filename] )
except:
passRuns the help ok, but then my program interface 'hang's, ie the help program
is still attatched to my gui. If I close the help, my gui comes back. If I
click on the task bar to get back my gui, my gui is just an unresponsive
blurred mess.
Calling os.spawn*() with os.P_WAIT will result in the thread that called
the function to stall waiting for the created process to finish, as per
the documentation. There are many ways around this;* Wrap the above into a new thread.
* Use os.P_NOWAIT instead.
* Use the subprocess module (built in with Python 2.4 and later).
* Use the wx.Execute/wx.Process pair.
Is there a "best" way to choose?
Andreas
os.spawn* and friends are generally shunned for subprocess in recent
Pythons. subprocess allows for all of the niceities of the os.spawn
family (incoming/outgoing pipes, etc.), but lacks the potential
asynchronicity of them (see my recipe here that fixes it: Module to allow Asynchronous subprocess use on Windows and Posix platforms « Python recipes « ActiveState Code).
Generally, I use the following discrimation: if you don't need
notification of the program ending, and are using Python 2.4 or later,
use subprocess. If you want an event when the program ends, or are using
Python 2.3 and prior, use wx.Execute/wx.Process.
- Josiah
Andreas Baumgartner <gigl@giglserver.de> wrote:
> Calling os.spawn*() with os.P_WAIT will result in the thread that called
> the function to stall waiting for the created process to finish, as per
> the documentation. There are many ways around this;
>
> * Wrap the above into a new thread.
> * Use os.P_NOWAIT instead.
> * Use the subprocess module (built in with Python 2.4 and later).
> * Use the wx.Execute/wx.Process pair.Is there a "best" way to choose?
Thought I'd try a version of wxPython latter than 2.6.
My Application keeps gpf's on exit... This makes no sense to me.
My first suspect was the App class, so I started inspecting my OnInit
and discovered that if I comment out the piece where it sets both
AppName & VendorName... I get to run it once w/out crash then the next
execution, it crashes (gpf) on exit.
I've tried commenting out the config.read/writes and that doesn't appear
to have any affect.
I haven't been able to isolate the cause any further.
XP, Python 2.4 & wxPython 2.8 I think this behavior also existed in 2.7
Commenting app/vendor settings works for one execution of my program,
but then subsequent executions also gpf.
Joseph
By chance do you have any wxTimers running in your app that you are
not explicitly calling Stop on during application exit?
On 1/31/07, Joe Brown <joebrown@podiatryfl.com> wrote:
Thought I'd try a version of wxPython latter than 2.6.
My Application keeps gpf's on exit... This makes no sense to me.
My first suspect was the App class, so I started inspecting my OnInit
and discovered that if I comment out the piece where it sets both
AppName & VendorName... I get to run it once w/out crash then the next
execution, it crashes (gpf) on exit.I've tried commenting out the config.read/writes and that doesn't appear
to have any affect.I haven't been able to isolate the cause any further.
XP, Python 2.4 & wxPython 2.8 I think this behavior also existed in 2.7
Commenting app/vendor settings works for one execution of my program,
but then subsequent executions also gpf.Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
--
Dj Gilcrease
OpenRPG Developer
~~http://www.openrpg.com
OpenRPG+ Lead Developer
~~http://openrpg.digitalxero.net
XeroPortal Creator
~~http://www.digitalxero.net
Web Admin for Thewarcouncil.us
~~http://www.thewarcouncil.us
Joe Brown wrote:
Thought I'd try a version of wxPython latter than 2.6.
My Application keeps gpf's on exit... This makes no sense to me.
My first suspect was the App class, so I started inspecting my OnInit
and discovered that if I comment out the piece where it sets both
AppName & VendorName... I get to run it once w/out crash then the next
execution, it crashes (gpf) on exit.I've tried commenting out the config.read/writes and that doesn't appear
to have any affect.I haven't been able to isolate the cause any further.
XP, Python 2.4 & wxPython 2.8 I think this behavior also existed in 2.7
Commenting app/vendor settings works for one execution of my program,
but then subsequent executions also gpf.
So, if it is related to the config, this leads me to believe that it has to do with using values that are read from the config instead of whatever you use for defaults, (because changing the app/vendor names would essentially mean you are starting without a config the time that works.) If that doesn't help you track it down further then try making a sample app that does nothing but use a config object similar to how you are doing it in your app, and see if that duplicates the problem.
http://wiki.wxpython.org/index.cgi/MakingSampleApps
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Thanks for the reply, as always!
I'm so sorry to bother you, I discovered the issue was related to my
foobaz.
Tried once already to do the sample, but the suspected code, didn't gpf.
After reading your anticipated suggestion of creating a sample, I was
more vigilant and found the culprit.
In wx2.6 this didn't cause an issue. Although I'm pretty sure it was
never a good idea to write a sizer like this:
self.panel = wx.Panel(self, -1)
self.Sizer = wx.BoxSizer(wx.VERTICAL)
self.Sizer.Add(self.panel, 1, wx.EXPAND)
self.panel.SetSizer(self.Sizer)
I can't quite configure how adjusting the config avoided gpf on close,
perhaps because I store the frame's size/ismaximized settings... But I
suppose it's a moot point.
I was hoping the issue I was stubbing my toe on, might be the cause of
another issue, but I don't see that a possibility now.
Joseph
On Wed, 2007-01-31 at 16:49 -0800, Robin Dunn wrote:
Joe Brown wrote:
> Thought I'd try a version of wxPython latter than 2.6.
>
> My Application keeps gpf's on exit... This makes no sense to me.
>
> My first suspect was the App class, so I started inspecting my OnInit
> and discovered that if I comment out the piece where it sets both
> AppName & VendorName... I get to run it once w/out crash then the next
> execution, it crashes (gpf) on exit.
>
> I've tried commenting out the config.read/writes and that doesn't appear
> to have any affect.
>
> I haven't been able to isolate the cause any further.
>
> XP, Python 2.4 & wxPython 2.8 I think this behavior also existed in 2.7
>
> Commenting app/vendor settings works for one execution of my program,
> but then subsequent executions also gpf.So, if it is related to the config, this leads me to believe that it has
to do with using values that are read from the config instead of
whatever you use for defaults, (because changing the app/vendor names
would essentially mean you are starting without a config the time that
works.) If that doesn't help you track it down further then try making
a sample app that does nothing but use a config object similar to how
you are doing it in your app, and see if that duplicates the problem.
Joe Brown wrote:
In wx2.6 this didn't cause an issue. Although I'm pretty sure it was
never a good idea to write a sizer like this:self.panel = wx.Panel(self, -1)
self.Sizer = wx.BoxSizer(wx.VERTICAL)
self.Sizer.Add(self.panel, 1, wx.EXPAND)
self.panel.SetSizer(self.Sizer)
You are right. A sizer should never contain the window that it belongs to.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!