is there a way to make a class behave like a modal dialog but without the
dialog ?
What I want to do is to open a couple of dialogs from the class. The result
will be asynchronously processed by the server, thus I have to wait in the
caller for the class to "EndModal". Basically I want to block the caller
until the class instance is destroyed.
I could do some kind of blocking loop, but maybe there is a better way.
THX
UC
- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
----- Original Message -----
From: "Uwe C. Schroeder" <uwe@oss4u.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Friday, November 07, 2003 4:57 PM
Subject: [wxPython-users] Modal like behaviour
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
is there a way to make a class behave like a modal dialog but without the
dialog ?
What I want to do is to open a couple of dialogs from the class. The result
will be asynchronously processed by the server, thus I have to wait in the
caller for the class to "EndModal". Basically I want to block the caller
until the class instance is destroyed.
I could do some kind of blocking loop, but maybe there is a better way.
THX
UC
- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
It's not about avoiding the block, it's about creating one.
Have you investigated threading? ...
From: "Uwe C. Schroeder" <uwe@oss4u.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Friday, November 07, 2003 4:57 PM
Subject: [wxPython-users] Modal like behaviour
Hi,
is there a way to make a class behave like a modal dialog but without the
dialog ?
What I want to do is to open a couple of dialogs from the class. The result
will be asynchronously processed by the server, thus I have to wait in the
caller for the class to "EndModal". Basically I want to block the caller
until the class instance is destroyed.
I could do some kind of blocking loop, but maybe there is a better way.
THX
UC
- --
UC
- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
···
On Thursday 06 November 2003 10:39 pm, Ben Catanzariti wrote:
Threads will allow you to manage multiple processes both synchronously and
asynchronously
···
----- Original Message -----
From: "Uwe C. Schroeder" <uwe@oss4u.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Friday, November 07, 2003 7:29 PM
Subject: Re: [wxPython-users] Modal like behaviour
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It's not about avoiding the block, it's about creating one.
On Thursday 06 November 2003 10:39 pm, Ben Catanzariti wrote:
Have you investigated threading? ...
----- Original Message -----
From: "Uwe C. Schroeder" <uwe@oss4u.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Friday, November 07, 2003 4:57 PM
Subject: [wxPython-users] Modal like behaviour
Hi,
is there a way to make a class behave like a modal dialog but without the
dialog ?
What I want to do is to open a couple of dialogs from the class. The
result
will be asynchronously processed by the server, thus I have to wait in the
caller for the class to "EndModal". Basically I want to block the caller
until the class instance is destroyed.
I could do some kind of blocking loop, but maybe there is a better way.
THX
UC
- --
UC
- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.423 / Virus Database: 238 - Release Date: 25/11/2002
is there a way to make a class behave like a modal dialog but without the dialog ?
What I want to do is to open a couple of dialogs from the class. The result will be asynchronously processed by the server, thus I have to wait in the caller for the class to "EndModal". Basically I want to block the caller until the class instance is destroyed. I could do some kind of blocking loop, but maybe there is a better way.
Maybe something like:
while not done:
wxYield()
But be careful to prevent the user from opening the same windows again and potentially getting into a recursive wxYield.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Hi
New to threads after years of avoiding them I now need them.
But which modules do I use. The references quote threads threading etc.
but I notice wxThreads and wonder where it fits in.
Any hints of links appreciated.
Thanks in advance.
Greg
wxThreads doesn't fit in. It's one of the many parts of wxWidgets that
Robin doesn't wrap because there's already a usable equivalent in
Python.
As far as what you should use, most typically the 'threading' module is
the best way. Just be aware that Python threads are not the most
efficient implementation.
Regards,
···
On Thu, 2004-09-02 at 15:06, Greg Binns wrote:
Hi
New to threads after years of avoiding them I now need them.
But which modules do I use. The references quote threads threading etc.
but I notice wxThreads and wonder where it fits in.
New to threads after years of avoiding them I now need them.
But which modules do I use. The references quote threads threading
etc. but I notice wxThreads and wonder where it fits in.
Use the standard Python threading module. Use Queue.Queue to send
information from your gui thread to your worker threads. Use wx.PostMessage and custom events to send messages from the worker
threads back to the main gui thread.
Do all your gui work in one thread or the sky will fall down.
You can use thread.get_ident() to get a unique id for the
currently running thread. Save the value somewhere and
litter your code with assertions:
> New to threads after years of avoiding them I now need them.
> But which modules do I use. The references quote threads threading
> etc. but I notice wxThreads and wonder where it fits in.
Use the standard Python threading module. Use Queue.Queue to send
information from your gui thread to your worker threads. Use
wx.PostMessage and custom events to send messages from the worker
threads back to the main gui thread.
I have some expirence with using Python standard threads together with
wxPython. Generally this works fine. There is a handy function
"wx.CallAfter" exists that invoke your route in context of GUI thread.
Don't hovewer be "too fancy". For example I got a lot of troubles then
trying to run wx.App in a background thread (for unittesting purposes).
New to threads after years of avoiding them I now need them.
But which modules do I use. The references quote threads threading
etc. but I notice wxThreads and wonder where it fits in.
Use the standard Python threading module. Use Queue.Queue to
send information from your gui thread to your worker threads.
Use wx.PostMessage and custom events to send messages from the
worker threads back to the main gui thread.
Don't forget about wx.CallAfter and wx.FutureCall:
They're both just convenience functions that wrap up other
things (like wx.PostMessage, and wx.Timer). But for me, they're
often exactly the right thing.
Don't hovewer be "too fancy". For example I got a lot of troubles then
trying to run wx.App in a background thread (for unittesting purposes).
I can attest to this. From experience, is seems like App instances prefer being in the dominate thread, waiting indefinitely to process events if not. However, I discovered a clever hack that fools wx into playing nice. By not directly importing your wx code, but instead using a proxy class to import, instantiate, and call App.Mainloop for you, you can adequately thread a "background" App instance. It's a little awkward, and definitely a roundabout way to getting things done, but it's nice to know about.
Don't hovewer be "too fancy". For example I got a lot of troubles then
trying to run wx.App in a background thread (for unittesting purposes).
I can attest to this. From experience, is seems like App instances
prefer being in the dominate thread, waiting indefinitely to process
events if not. However, I discovered a clever hack that fools wx into
playing nice. By not directly importing your wx code, but instead using
a proxy class to import, instantiate, and call App.Mainloop for you, you
can adequately thread a "background" App instance. It's a little
awkward, and definitely a roundabout way to getting things done, but
it's nice to know about.
Could you add that to the wiki or post to this list? It would be
interesting reading about that.
This is just for amusement. I spotted the following delightful typo in the
C++ docs.
···
------------------
wxPen::operator ==
bool operator ==(const wxPen& pen)
Equality operator. Two pens are equal if they contain pointers to the same
underlying pen data. It does not compare each attribute, so two
independently-created pens using the same parameters will fail the test.
------------------
wxFont::operator ==
bool operator ==(const wxFont& font)
Equality operator. Two fonts are equal if they contain pointers to the same
underlying font data. It does not compare each attribute, so two
indefontdently-created fonts using the same parameters will fail the test.
------------------
Clearly the second one was copied from the first one, and all occurrences of
'pen' were changed to 'font'. Note how 'independently' has become
'indefontdently'
I can attest to this. From experience, is seems like App instances prefer being in the dominate thread, waiting indefinitely to process events if not. However, I discovered a clever hack that fools wx into playing nice. By not directly importing your wx code, but instead using a proxy class to import, instantiate, and call App.Mainloop for you, you can adequately thread a "background" App instance. It's a little awkward, and definitely a roundabout way to getting things done, but it's nice to know about.
Could you add that to the wiki or post to this list? It would be
interesting reading about that.
If you mean some example code, then certainly. It's actually rather simple:
## the normal way wx doesn't like #import Gui #app = Gui.App() #t = threading.Thread(target=app.MainLoop) #t.start()
## work around
app = SelfImportingProxyClass(imp='Gui', obj='App', call='MainLoop')
t = threading.Thread(target=app)
t.start()
# go about your buisness...
I can attest to this. From experience, is seems like App instances prefer being in the dominate thread, waiting indefinitely to process events if not. However, I discovered a clever hack that fools wx into playing nice. By not directly importing your wx code, but instead using a proxy class to import, instantiate, and call App.Mainloop for you, you can adequately thread a "background" App instance. It's a little awkward, and definitely a roundabout way to getting things done, but it's nice to know about.
Could you add that to the wiki or post to this list? It would be
interesting reading about that.
I've done something similar to this, but instead of a proxy class, I simply subclassed threading.Thread and imported wx inside of the overridden run() method -- that method being the default "target" parameter for Thread.start(). (To be completely accurate, I imported wxPython.wx, as this was using wxPython2.3 ...) I needed to run my wxApp in a background thread because it was intended to be controlled through a COM object inside of another app (using Queues to pass commands/responses back and forth). However, for reasons that never became clear to me, this didn't always work -- maybe half the time I'd get assertions complaining about needing to be in the main thread. This may or may not have been because I was doing something improperly, and may or may not have had more to do with the other layers of host application that are beyond my control.
I ended up resolving this by launching the wxPython app as an independent process and communicating via sockets, which has been working much more cleanly...
Jeff Shannon
Technician/Programmer
Credit International
Don't hovewer be "too fancy". For example I got a lot of troubles then
trying to run wx.App in a background thread (for unittesting purposes).
I can attest to this. From experience, is seems like App instances prefer being in the dominate thread, waiting indefinitely to process events if not. However, I discovered a clever hack that fools wx into playing nice. By not directly importing your wx code, but instead using a proxy class to import, instantiate, and call App.Mainloop for you, you can adequately thread a "background" App instance. It's a little awkward, and definitely a roundabout way to getting things done, but it's nice to know about.
Have you tried it in 2.5? I think that since wxWidgets initialization has been moved from import to app creation that whichever thread creates the app object (and therefore initializes wxWidgets) will be the one that is considered the gui thread. Havn't tried it though...
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Have you tried it in 2.5? I think that since wxWidgets initialization has been moved from import to app creation that whichever thread creates the app object (and therefore initializes wxWidgets) will be the one that is considered the gui thread. Havn't tried it though...
That's essentially the root of the problem, and fortunately, the solution as well. If the thread that imports wx has any other threads, wx blocks waiting for the other threads to terminate. By importing wx into it's own class and threading that class instance, wx can essentially see no other threads, and so, runs smoothly. The code I posted was written for 2.5.
Personally, I'd prefer no distinction between "gui" and "non-gui" threads. One annoying design paradigm I see prevalent in many gui packages is an insistence on being the dominate object, through which even non-gui operations should be routed (epitomized in wx.App). My ideal gui would be one where a window is unlike any other object, and can be instantiated and deleted at will. However, in all fairness, of all the gui packages I've tried, wx gives me the most freedom in this regard.
That's essentially the root of the problem, and fortunately, the
solution as well. If the thread that imports wx has any other threads,
wx blocks waiting for the other threads to terminate. By importing wx
into it's own class and threading that class instance, wx can
essentially see no other threads, and so, runs smoothly. The code I
posted was written for 2.5.
I have been doing this with 2.5 too. It "almost works". My gui thread
basically opens different dialog boxes based on events received. My main
thread reads the console input, parses a command then sends an event to the
gui thread that will display the right dialog box.
Now the problem : the first time the dialog box is called (.ShowModal()),
the key events are still assigned to the console, no matter I do SetFocus()
or whatever in the gui thread. If I click on the title bar of the dialog
box, it will gain focus for good. If I dismiss it and call it again, it is
ok too.
I'm a bit stuck by now because I wanted to use this hack from (x)emacs to
implement a couple of wizards. Unfortunately I feel there is a bad
interaction about who has the focus when you use this wxPython hack. Calling
this from xemacs (start-process) make the thing hang on wxpython side about
4 out of 5 times. Sometimes it initializes ok. But I have not been able to
locate the precise reason. Except that using it from the console and without
xemacs, the dialog box doesn't get the key events.
Any idea to make it work would be really appreciated.
