Hi all,
I am using wxPython 2.4.0.1 and Python 2.2.1 on Win2K, SP2.
I am using threads for a long-ish serial download process in my GUI app.
The problem I am having is with the wxBegin/EndBusyCursor functions. I
set the cursor to busy, then I run my new thread to download, which
calls wxSafeYield() periodically to allow GUI updates to happen. Well,
as soon as the new thread starts, the cursor reverts to it's 'unbusy'
state. I have tried setting it back to busy in the other thread, but
this obviously does not work. If I call wxYield() (rather than
wxSafeYield), it works fine, but allows dangerous access to my GUI,
creating the potential of calling wxYield() 'recursively' and crashing
the program.
Is there any thread-safe way to keep the cursor busy? Does it involve
wxMutexGUIEnter/Leave functions in any way?
Thanks in advance for any suggestions,
Mark.
Well, the point of locking the GUI is so that the user cannot click Tools...Download, and spawn a second process.
You could just gray out (disable) the menu item until the thread returns.
ยทยทยท
At 03:40 PM 1/15/2003 -0500, you wrote:
Also, I have an upload function which also locks the GUI from user input the same way, but updates the screen with hunks of data as it is uploading. The whole motivation for the separate thread was because without it, if it takes too long, the app locks (the good ole' 'Not Responding' in Windows task manager). I assumed this was because it could not respond to normal paint events etc.
Anyway, a separate thread is definitely the way to go here, the question is then - what is the *proper* way to disable user input. It sounds like I need to look into wxWindowDisabler.
Thanks,
Mark.
cbarker@dspfactory.com wrote:
Mark melvin wrote:
I am using threads for a long-ish serial download process in my GUI app.
The problem I am having is with the wxBegin/EndBusyCursor functions. I
set the cursor to busy, then I run my new thread to download,
My first question is: why do you want to do this? The reason you want
the download to run in a separate thread is so that the whole app is NOT
busy while it's happening. If you want the whole app to lock up and
wait, then there's no need for the separate thread. If you want users to
be able to interact with the app while the download is happening, then a
busy cursor is not appropriate. What you probably want instead is some
kind of progress bar. Look in the demo for the threads example, and in
the Wiki for the long running processes discussion for some ideas about
how to do this.
-Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org