Introduction

The following was posted to the comp.lang.python newsgroup on 24-May-2001. Since it explains very well the options for keeping the GUI responsive when the application has to do long running tasks I decided to copy it here verbatim. Many thanks to David Bolen for taking the time and effort to compose and post this message.

--Robin

The Question

Daniel Frame writes:

David's Response

There's really three possibilities I would think of - threading, wxYield, or chunking up your processing in a wxEVT_IDLE handler. I've given a small sample of each below.

I personally like threads for this sort of thing (I think they leave the UI the most responsive), but there's no hard and fast rule. So whichever you're more comfortable with.

Threading really isn't that hard - you can just start up a thread to do your processing, and have it send an event to your main GUI thread when it has completed. While it is working, it can check an event object or some other flag variable to indicate that it should give up and stop.

For a simple sort of example, here's a small bit of code that presents a simple (really dumb visually) frame, and uses a worker thread to simulate some processing (that takes 10s, resulting in a value of 10), while permitting it to be aborted. This could be extrapolated to doing any sort of lengthy processing and returning any sort of result. Intermediate events could be generated during the processing to give some indication to the main GUI thread of how things were proceeding (perhaps updating something like a gauge or some other visual indicator).

   1 import time
   2 from threading import *
   3 import wx
   4 
   5 # Button definitions
   6 ID_START = wx.NewId()
   7 ID_STOP = wx.NewId()
   8 
   9 # Define notification event for thread completion
  10 EVT_RESULT_ID = wx.NewId()
  11 
  12 def EVT_RESULT(win, func):
  13     """Define Result Event."""
  14     win.Connect(-1, -1, EVT_RESULT_ID, func)
  15 
  16 class ResultEvent(wx.PyEvent):
  17     """Simple event to carry arbitrary result data."""
  18     def __init__(self, data):
  19         """Init Result Event."""
  20         wx.PyEvent.__init__(self)
  21         self.SetEventType(EVT_RESULT_ID)
  22         self.data = data
  23 
  24 # Thread class that executes processing
  25 class WorkerThread(Thread):
  26     """Worker Thread Class."""
  27     def __init__(self, notify_window):
  28         """Init Worker Thread Class."""
  29         Thread.__init__(self)
  30         self._notify_window = notify_window
  31         self._want_abort = 0
  32         # This starts the thread running on creation, but you could
  33         # also make the GUI thread responsible for calling this
  34         self.start()
  35 
  36     def run(self):
  37         """Run Worker Thread."""
  38         # This is the code executing in the new thread. Simulation of
  39         # a long process (well, 10s here) as a simple loop - you will
  40         # need to structure your processing so that you periodically
  41         # peek at the abort variable
  42         for i in range(10):
  43             time.sleep(1)
  44             if self._want_abort:
  45                 # Use a result of None to acknowledge the abort (of
  46                 # course you can use whatever you'd like or even
  47                 # a separate event type)
  48                 wx.PostEvent(self._notify_window, ResultEvent(None))
  49                 return
  50         # Here's where the result would be returned (this is an
  51         # example fixed result of the number 10, but it could be
  52         # any Python object)
  53         wx.PostEvent(self._notify_window, ResultEvent(10))
  54 
  55     def abort(self):
  56         """abort worker thread."""
  57         # Method for use by main thread to signal an abort
  58         self._want_abort = 1
  59 
  60 # GUI Frame class that spins off the worker thread
  61 class MainFrame(wx.Frame):
  62     """Class MainFrame."""
  63     def __init__(self, parent, id):
  64         """Create the MainFrame."""
  65         wx.Frame.__init__(self, parent, id, 'Thread Test')
  66 
  67         # Dumb sample frame with two buttons
  68         wx.Button(self, ID_START, 'Start', pos=(0,0))
  69         wx.Button(self, ID_STOP, 'Stop', pos=(0,50))
  70         self.status = wx.StaticText(self, -1, '', pos=(0,100))
  71 
  72         self.Bind(wx.EVT_BUTTON, self.OnStart, id=ID_START)
  73         self.Bind(wx.EVT_BUTTON, self.OnStop, id=ID_STOP)
  74 
  75         # Set up event handler for any worker thread results
  76         EVT_RESULT(self,self.OnResult)
  77 
  78         # And indicate we don't have a worker thread yet
  79         self.worker = None
  80 
  81     def OnStart(self, event):
  82         """Start Computation."""
  83         # Trigger the worker thread unless it's already busy
  84         if not self.worker:
  85             self.status.SetLabel('Starting computation')
  86             self.worker = WorkerThread(self)
  87 
  88     def OnStop(self, event):
  89         """Stop Computation."""
  90         # Flag the worker thread to stop if running
  91         if self.worker:
  92             self.status.SetLabel('Trying to abort computation')
  93             self.worker.abort()
  94 
  95     def OnResult(self, event):
  96         """Show Result status."""
  97         if event.data is None:
  98             # Thread aborted (using our convention of None return)
  99             self.status.SetLabel('Computation aborted')
 100         else:
 101             # Process results here
 102             self.status.SetLabel('Computation Result: %s' % event.data)
 103         # In either event, the worker is done
 104         self.worker = None
 105 
 106 class MainApp(wx.App):
 107     """Class Main App."""
 108     def OnInit(self):
 109         """Init Main App."""
 110         self.frame = MainFrame(None, -1)
 111         self.frame.Show(True)
 112         self.SetTopWindow(self.frame)
 113         return True
 114 
 115 if __name__ == '__main__':
 116     app = MainApp(0)
 117     app.MainLoop()

Oh, and if you're concerned with hanging on an exit if your thread doesn't terminate for some reason, just add a "self.setDaemon(1)" to the init and Python won't wait for it to terminate.

The second approach, using wxYield, should be fine too - just add a call to wxYield() somewhere within the computation code such that it executes periodically. At that point, any pending window events will be dispatched (permitting the window to refresh, process button presses, etc...). Then, it's similar to the above in that you set a flag so that when the original code gets control after the wxYield() returns it knows to stop processing.

As with the threading case, since all events go through during the wxYield() you need to protect against trying to run the same operation twice.

Here's the equivalent of the above but placing the computation right inside the main window class. Note that one difference is that unlike with threading, the responsiveness of your GUI is now directly related to how frequently you call wxYield, so you may have delays refreshing your window dependent on that frequency. You should notice that this is a bit more sluggish with its frequency of a wxYield() each second.

   1 import time
   2 import wx
   3 
   4 # Button definitions
   5 ID_START = wx.NewId()
   6 ID_STOP = wx.NewId()
   7 
   8 # GUI Frame class that spins off the worker thread
   9 class MainFrame(wx.Frame):
  10     """Class MainFrame."""
  11     def __init__(self, parent, id):
  12         """Create the MainFrame."""
  13         wx.Frame.__init__(self, parent, id, 'wxYield Test')
  14 
  15         # Dumb sample frame with two buttons
  16         wx.Button(self, ID_START, 'Start', pos=(0,0))
  17         wx.Button(self, ID_STOP, 'Stop', pos=(0,50))
  18         self.status = wx.StaticText(self, -1, '', pos=(0,100))
  19 
  20         self.Bind (wx.EVT_BUTTON, self.OnStart, id=ID_START)
  21         self.Bind (wx.EVT_BUTTON, self.OnStop, id=ID_STOP)
  22 
  23         # Indicate we aren't working on it yet
  24         self.working = 0
  25 
  26     def OnStart(self, event):
  27         """Start Computation."""
  28         # Start the processing - this simulates a loop - you need to call
  29         # wx.Yield at some periodic interval.
  30         if not self.working:
  31             self.status.SetLabel('Starting Computation')
  32             self.working = 1
  33             self.need_abort = 0
  34 
  35             for i in range(10):
  36                 time.sleep(1)
  37                 wx.Yield()
  38                 if self.need_abort:
  39                     self.status.SetLabel('Computation aborted')
  40                     break
  41             else:
  42                 # Here's where you would process the result
  43                 # Note you should only do this if not aborted.
  44                 self.status.SetLabel('Computation Completed')
  45 
  46             # In either event, we aren't running any more
  47             self.working = 0
  48 
  49     def OnStop(self, event):
  50         """Stop Computation."""
  51         if self.working:
  52             self.status.SetLabel('Trying to abort computation')
  53             self.need_abort = 1
  54 
  55 class MainApp(wx.App):
  56     """Class Main App."""
  57     def OnInit(self):
  58         """Init Main App."""
  59         self.frame = MainFrame(None,-1)
  60         self.frame.Show(True)
  61         self.SetTopWindow(self.frame)
  62         return True
  63 
  64 if __name__ == '__main__':
  65     app = MainApp(0)
  66     app.MainLoop()

And finally, you can do your work within an idle handler. In this case, you let wxPython generate an IDLE event whenever it has completed processing normal user events, and then you perform a "chunk" of your processing in each such case. This can be a little tricker depending on your algorithm since you have to be able to perform the work in discrete pieces. Inside your IDLE handler, you request that it be called again if you aren't done, but you want to make sure that each pass through the handler doesn't take too long. Effectively, each event is similar to the gap between wxYield() calls in the previous example, and your GUI responsiveness will be subject to that latency just as with the wxYield() case.

I'm also not sure you can remove an idle handler once established (or at least I think I had problems with that in the past), so the code below just establishes it once and the handler only does work if it's in the midst of a computation. [Actually, you can use the Disconnect method to remove an event handler binding, although there is no real need to do so as there is very little overhead if you use a guard condition as in the code below. --Robin]

   1 import time
   2 import wx
   3 
   4 # Button definitions
   5 ID_START = wx.NewId()
   6 ID_STOP = wx.NewId()
   7 
   8 # GUI Frame class that spins off the worker thread
   9 class MainFrame(wx.Frame):
  10     """Class MainFrame."""
  11     def __init__(self, parent, id):
  12         """Create the MainFrame."""
  13         wx.Frame.__init__(self, parent, id, 'Idle Test')
  14 
  15         # Dumb sample frame with two buttons
  16         wx.Button(self, ID_START, 'Start',p os=(0,0))
  17         wx.Button(self, ID_STOP, 'Stop', pos=(0,50))
  18         self.status = wx.StaticText(self, -1, '', pos=(0,100))
  19 
  20         self.Bind (wx.EVT_BUTTON, self.OnStart, id=ID_START)
  21         self.Bind (wx.EVT_BUTTON, self.OnStop, id=ID_STOP)
  22         self.Bind (wx.EVT_IDLE, self.OnIdle)
  23 
  24         # Indicate we aren't working on it yet
  25         self.working = 0
  26 
  27     def OnStart(self, event):
  28         """Start Computation."""
  29         # Set up for processing and trigger idle event
  30         if not self.working:
  31             self.status.SetLabel('Starting Computation')
  32             self.count = 0
  33             self.working = 1
  34             self.need_abort = 0
  35 
  36     def OnIdle(self, event):
  37         """Idle Handler."""
  38         if self.working:
  39             # This is where the processing takes place, one bit at a time
  40             if self.need_abort:
  41                 self.status.SetLabel('Computation aborted')
  42             else:
  43                 self.count = self.count + 1
  44                 time.sleep(1)
  45                 if self.count < 10:
  46                     # Still more work to do so request another event
  47                     event.RequestMore()
  48                     return
  49                 else:
  50                     self.status.SetLabel('Computation completed')
  51 
  52             # Reaching here is an abort or completion - end in either case
  53             self.working = 0
  54 
  55     def OnStop(self, event):
  56         """Stop Computation."""
  57         if self.working:
  58             self.status.SetLabel('Trying to abort computation')
  59             self.need_abort = 1
  60 
  61 class MainApp(wx.App):
  62     """Class Main App."""
  63     def OnInit(self):
  64         """Init Main App."""
  65         self.frame = MainFrame(None, -1)
  66         self.frame.Show(True)
  67         self.SetTopWindow(self.frame)
  68         return True
  69 
  70 if __name__ == '__main__':
  71     app = MainApp(0)
  72     app.MainLoop()


Slight modification for recursive tasks

Jeff Grimmett adds:

The above three examples got me going in the right direction, but the actual worker task used is a little on the simple side for what I needed to do, which was to recurse through directories and use the same class for each recursion.

Do I need to tell you that it's a bad idea to recurse 100 threads at once? :-) Highly entertaining to watch but hardly useful of the end goal is to collect data serially!

The trick I settled on was to seperate the thread from the task. The means of communicating the shutdown command was the first thing I tackled. I settled on the python threading module's Event class. This class is basically a flag, which i suppose would also work quite well as long as the scope is correct.

   1 import  threading
   2 
   3 # This is a global flag that we will manipulate as needed
   4 # to allow graceful exit from the recursive search.
   5 KeepRunning     =       threading.Event()

The next thing I needed to do was define the scope of the actual worker thread.

   1 class   Worker(threading.Thread):
   2   def __init__ (self, op, dir1, dir2):
   3   threading.Thread.__init__(self)
   4   self.op   = op
   5   self.Dir1 = dir1
   6   self.Dir2 = dir2
   7   KeepRunning.set()
   8 
   9   self.start()
  10 
  11   def run(self):
  12     self.wb = WorkerBee(self.op, self.Dir1, self.Dir2)
  13     self.op.AppendText('Done!\n')
  14     wxBell()
  15 
  16     # Assuming you are following the above example somewhat, assume that this is a
  17     # similar 'reporting' event class that we are calling. It carries a cargo which
  18     # is in fact the 'head' WorkerBee.
  19     wxPostEvent(self.op.GetParent(), NewReport(self.wb))
  20 
  21   def abort(self):
  22     KeepRunning.clear()
  23 
  24   # print to the output window.
  25   def Update(self, txt):
  26     self.op.AppendText(txt)
  27     self.op.ShowPosition(self.op.GetLastPosition()) # keeps the last line visible

The thread initializes with a pointer to the output window - which in this case is a wxTextCtrl() object - and the starting directory. Like the above example, this thread is self-starting, but need not be.

The first big difference is in the run() method. In the above example all the work is actually done BY the run() method. In this case, we create a WorkerBee object and retain a handle on it. Exactly why will become clear in a moment.

The second difference is that instead of keeping our 'keep running' variable local, we now have it global in the form of the KeepGoing Event object. Again, the reason why becomes clear in the next part.

While not directly on topic, the Update() method is simply a convenience to deal with the output display. If you were going to stdout this would be entirely uncessesary.

====

The WorkerBee class is the main point of difference between this example and the previous. Instead of the thread object doing all the work, it starts up the WorkerBee object.

The WorkerBee class recursively scans two directories and compares the results using the filecmp Python module. The exact task is not important, but I had to use something :-)

   1 class WorkerBee:
   2   def __init__ (self, op, dir1, dir2):
   3     self.DiffList = []  # We will retain a list of changed files
   4     self.DirList  = []  # We will retain a list of directories.
   5     self.A        = dir1
   6     self.B        = dir2
   7     self.op       = op
   8 
   9     self.Update('scanning %s\n' % self.A)
  10 
  11     self.cmp = filecmp.dircmp(self.A, self.B)
  12                 
  13     self.Deleted = self.cmp.left_only
  14     self.New     = self.cmp.right_only
  15     self.Files   = self.cmp.common_files
  16     self.Dirs    = self.cmp.common_dirs
  17 
  18     for i in self.Files :
  19      if not KeepRunning.isSet(): break  
  20 
  21        self.Update('\t%s\\%s' %(self.A,i)) 
  22 
  23        if filecmp.cmp('%s\\%s' % (self.A, i), '%s\\%s' % (self.B, i), shallow=0) == 0 :
  24          self.Update('\t<---- DIFF ***\n')      # A diff!
  25          self.DiffList.append(i)
  26        else:
  27          self.Update('\n')
  28 
  29     for i in self.Dirs  :
  30       if not KeepRunning.isSet(): break 
  31 
  32       self.DirList.append ( WorkerBee ( op,
  33                                         '%s\\%s' % (self.A, i), 
  34                                         '%s\\%s' % (self.B, i)
  35                                       )
  36                           )
  37 
  38   def   Update(self, txt):
  39     self.op.AppendText(txt)
  40     self.op.ShowPosition(self.op.GetLastPosition())

THIS is why we need to keep the thread object and the workerbee seperate. If the workerbee was built around the Thread class, we would have a SWARM of workerbees! However, in this case what we end up with is a controlled recursion into a directory tree, with frequent checks on the KeepRunning Event flag. The whole thing shuts down quite nicely and leaves the GUI VERY responsive.

More Tips

ChuckEsterbrook asked:

The LongRunningTasks wiki page doesn't mention using Queues. When people use this technique what is the set up? For example, is your "worker thread" pushing data into the queue and then a wx.Timer is polling it out with a non-blocking q.get_nowait()?

RobinDunn replied:

That's one way. Another is to call wxWakeUpIdle when the item is put in the Queue, and then have a EVT_IDLE handler that fetches items from the queue. That way the item is usually processed very soon after it is put there without having to have a higher frequency timer.

Another option is to not use the queue or wxPostEvent and just use wxCallAfter passing to it the callable and parameters to be called in the GUI thread. (It uses wxPostEvent internally.) The implementation and docs of wxCallAfter is in core.py.

MarienZwart would like to add:

This is actually (sort of) documented in the wxwidgets docs:

So you do not need a Queue to send messages from the worker thread to the main/gui thread: just use AddPendingEvent in the worker and a normal event handler in the gui. However if you need to send messages from the main/gui thread to the worker thread the right way to do it is probably a Queue, with the gui thread calling put() and the worker regularly checking for messages with get_nowait(). You can *probably* get away with using a simple boolean flag like some examples on this page use without any extra locking thanks to the GIL (Global Interpreter Lock), but for anything more complicated than that you need locking (like the Event used in the previous example), and for more than one kind of "message" a queue is usually the simplest way to go. Even something as simple as a worker thread that can be paused, resumed and cancelled is IMHO simpler using a queue than using a bunch of Event and/or Condition objects (the worker can just .get() on the queue to pause).


See also Brian Kelley's demo (Process.py) which shows how to do a long task in a separate process (using wxProcess and wxExecute) rather than a thread. A separate process is like running a separate application - it can run full speed, whereas a thread might be slowed about 30% by Python's global interpreter lock (I don't know which version you were using, but at least for the first few threads, Python does pretty well, resulting in fairly minimal overhead - Josiah).

MVoncken suggests: I prefer using a generator,(variant on wxYield,Example2):

   1         def DoSomeLongTask(self):
   2             """
   3             usualy defined somewhere else
   4             """
   5             for i in range(10):
   6                  time.sleep(1)  
   7                  yield i
   8 
   9         def OnStart(self, event):
  10             # Over-Simplified version.
  11             # iterate over DoSomeLongTask,call wxYield and display status
  12             for status in DoSomeLongTask():
  13                 #display status here.. (wx.ProgressBar?)  
  14                 wxYield()
  15                 if self.need_abort:
  16                         break


While using a generator and wx.Yield() works, you are limited to having a single long-running-task at any time. This may be a serious limitation to your application. Instead, you can use the built-in wx.FutureCall() function to schedule as many calls as you want/need. I use this in to handle 'replace all' in one of my applications.

Josiah suggests:

   1     def DoSomeLongTask(self, state):
   2         #pull the state out
   3         x,y,z = state
   4         if not self.need_abort:
   5             time.sleep(1)
   6             x -= 1
   7             if x > 0 and not self.need_abort:
   8                 wx.FutureCall(1, self.DoSomeLongTask, (x,y,z))
   9 
  10     def OnStart(self, event):
  11         # Over-Simplified version.
  12         self._DoSomeLongTask((10, 1, 2))

Alternatively, since wx.FutureCall creates and manipulates wx.Timer instances, we could just create a registry of stuff to call when a timer expires, and allow insertion of items to call into this registry. Why do we use a Timer/FutureCall instead of wx.CallAfter? It's mostly a matter of taste, but we use self.IsRunning() rather than keeping explicit state as a convenience.

Josiah also suggests:

   1 import traceback
   2 
   3 class CallRegistry(wx.Timer):
   4     def __init__(self, delay=1):
   5         wx.Timer.__init__(self)
   6         self.tasks = []
   7         if delay < 1:
   8             delay = 1
   9         self.delay = delay
  10     
  11     def Notify(self):
  12         tl = []
  13         otl = self.tasks
  14         self.tasks = []
  15         for x in otl:
  16             try:
  17                 i,j = x
  18                 x = i(j)
  19                 if x:
  20                     try:
  21                         i,j = x
  22                     except:
  23                         if callable(x):
  24                             tl.append((x, None))
  25                     else:
  26                         tl.append(x)
  27             except (KeyboardInterrupt, SystemExit):
  28                 raise
  29             except:
  30                 traceback.print_exc()
  31         self.tasks.extend(tl)
  32         if not self.tasks:
  33             self.Stop()
  34     
  35     def CallLater(self, fcn, state=None):
  36         self.tasks.append((fcn, state))
  37         if not self.IsRunning():
  38             self.Start(self.delay, wx.TIMER_CONTINUOUS)

Sample use of the above:

   1 class MyFrame(wx.Frame):
   2     def __init__(self, ...):
   3         ...
   4         self.cr = CallRegistry()
   5         self.cr.CallLater(self.Task1)
   6         self.cr.CallLater(self.Task2)
   7         ...
   8     
   9     def Task1(self, state):
  10         ...
  11         #automatically reschedules itself
  12         return self.Task1, newstate
  13     
  14     def Task2(self, state):
  15         ...
  16         if c1:
  17             #schedules some other task without arguments
  18             return self.Task3
  19         else:
  20             #reschedules itself again
  21             return self.Task2, newstate

Redirecting text from stdout to a wx.TextCtrl

I thought I might add this to the discussion. There are probably more ways than one to do this but... This is some sample code that I put together that updates a text control in wxpython from output being sent to stdout through backend "print" statments being executed in a separate thread.

The idea here is to that you're creating a class with a "write" method to rebind to stdout (the real value of stdout is always kept in sys.stdout for rebinding). Everytime a message is spit out to stdout an event is thrown out to the text control for processing. The problem is that the text control doesn't update itself. Therefore we need to get the control to process its pending events. Therefore we need to set up a timer that gets the text control to attempt to process its pending events every so often.

The threading code is pulled from Python in a Nutshell pretty much (which is what I'm using). It uses 2 Queues to process events. requestID, callable, args, kwds = self.requestQ.get() will suspend the thread untill the callable returns, and when it completes self.resultQ.put((requestID, callable(*args, **kwds))) will tell us that the process has finished its task. When this is done we submit an event to the GUI telling us that we are done.

There's better ways to poll the resultQ but for my purposes here this works pretty nicely. Anyway hope this is useful to someone...

   1 #!/usr/bin/env python
   2 
   3 import wx, threading, Queue, sys, time
   4 from wx.lib.newevent import NewEvent
   5 
   6 ID_BEGIN=100
   7 wxStdOut, EVT_STDDOUT= NewEvent()
   8 wxWorkerDone, EVT_WORKER_DONE= NewEvent()
   9 
  10 def LongRunningProcess(lines_of_output):
  11     for x in range(lines_of_output):
  12         print "I am a line of output (hi!)...."
  13         time.sleep(1)
  14 
  15 class MainFrame(wx.Frame):
  16     def __init__(self, parent, id, title):
  17         wx.Frame.__init__(self, parent, id, title, size=(300, 300))
  18         self.requestQ = Queue.Queue() #create queues
  19         self.resultQ = Queue.Queue()
  20                 
  21         #widgets
  22         p = wx.Panel(self)
  23         self.output_window = wx.TextCtrl(p, -1, 
  24                              style=wx.TE_AUTO_SCROLL|wx.TE_MULTILINE|wx.TE_READONLY)
  25         self.go = wx.Button(p, ID_BEGIN, 'Begin') 
  26         self.output_window_timer = wx.Timer(self.output_window, -1)
  27 
  28         #frame sizers
  29         sizer = wx.BoxSizer(wx.VERTICAL)
  30         sizer.Add(self.output_window, 10, wx.EXPAND)
  31         sizer.Add(self.go, 1, wx.EXPAND)
  32         p.SetSizer(sizer)
  33        
  34         #events
  35         wx.EVT_BUTTON(self, ID_BEGIN, self.OnBeginTest)
  36         self.output_window.Bind(EVT_STDDOUT, self.OnUpdateOutputWindow)
  37         self.output_window.Bind(wx.EVT_TIMER, self.OnProcessPendingOutputWindowEvents)
  38         self.Bind(EVT_WORKER_DONE, self.OnWorkerDone)
  39         
  40         #thread
  41         self.worker = Worker(self, self.requestQ, self.resultQ)
  42 
  43     def OnUpdateOutputWindow(self, event):
  44         value = event.text
  45         self.output_window.AppendText(value)
  46               
  47     def OnBeginTest(self, event):
  48         lines_of_output=7
  49         self.go.Disable()
  50         self.worker.beginTest(LongRunningProcess, lines_of_output)
  51         self.output_window_timer.Start(50)
  52     
  53     def OnWorkerDone(self, event):
  54         self.output_window_timer.Stop()
  55         self.go.Enable()
  56 
  57     def OnProcessPendingOutputWindowEvents(self, event):
  58         self.output_window.ProcessPendingEvents()
  59 
  60 class Worker(threading.Thread):
  61     requestID = 0
  62     def __init__(self, parent, requestQ, resultQ, **kwds):
  63         threading.Thread.__init__(self, **kwds) 
  64         self.setDaemon(True) 
  65         self.requestQ = requestQ
  66         self.resultQ = resultQ
  67         self.start() 
  68         
  69     def beginTest(self, callable, *args, **kwds):
  70         Worker.requestID +=1
  71         self.requestQ.put((Worker.requestID, callable, args, kwds))
  72         return Worker.requestID
  73 
  74     def run(self):
  75         while True:
  76             requestID, callable, args, kwds = self.requestQ.get()
  77             self.resultQ.put((requestID, callable(*args, **kwds))) 
  78             evt = wxWorkerDone()
  79             wx.PostEvent(wx.GetApp().frame, evt)
  80                                
  81 class SysOutListener:       
  82     def write(self, string):
  83         sys.__stdout__.write(string)
  84         evt = wxStdOut(text=string)
  85         wx.PostEvent(wx.GetApp().frame.output_window, evt)
  86     
  87 class MyApp(wx.App):
  88     def OnInit(self):
  89         self.frame = MainFrame(None, -1, 'rebinding stdout')
  90         self.frame.Show(True)
  91         self.frame.Center()
  92         return True
  93  
  94 #entry point
  95 if __name__ == '__main__':
  96     app = MyApp(0)
  97     sys.stdout = SysOutListener()
  98     app.MainLoop()

Easiest Implementation *Ever* :)

So you say you want to perform a long running task from a wxPython GUI? Well, it don't get no simpler than this! Use threads but don't mess with a separate thread class. Make sure if you're running in the other thread that you interact with the GUI via wx.CallAfter.

   1 import wx
   2 import thread
   3 from time import sleep
   4 
   5 class MainFrame(wx.Frame):
   6 
   7     def __init__(self, parent):
   8         wx.Frame.__init__(self, parent)
   9 
  10         self.label = wx.StaticText(self, label="Ready")
  11         self.btn = wx.Button(self, label="Start")
  12         self.gauge = wx.Gauge(self)
  13 
  14         sizer = wx.BoxSizer(wx.VERTICAL)
  15         sizer.Add(self.label, proportion=1, flag=wx.EXPAND)
  16         sizer.Add(self.btn, proportion=0, flag=wx.EXPAND)
  17         sizer.Add(self.gauge, proportion=0, flag=wx.EXPAND)
  18 
  19         self.SetSizerAndFit(sizer)
  20 
  21         self.Bind(wx.EVT_BUTTON, self.onButton)
  22 
  23     def onButton(self, evt):
  24         self.btn.Enable(False)
  25         self.gauge.SetValue(0)
  26         self.label.SetLabel("Running")
  27         thread.start_new_thread(self.longRunning, ())
  28 
  29     def onLongRunDone(self):
  30         self.gauge.SetValue(100)
  31         self.label.SetLabel("Done")
  32         self.btn.Enable(True)
  33 
  34     def longRunning(self):
  35         """This runs in a different thread.  Sleep is used to simulate a long running task."""
  36         sleep(3)
  37         wx.CallAfter(self.gauge.SetValue, 20)
  38         sleep(5)
  39         wx.CallAfter(self.gauge.SetValue, 50)
  40         sleep(1)
  41         wx.CallAfter(self.gauge.SetValue, 70)
  42         sleep(10)
  43         wx.CallAfter(self.onLongRunDone)
  44 
  45 if __name__ == "__main__":
  46     app = wx.PySimpleApp()
  47     app.TopWindow = MainFrame(None)
  48     app.TopWindow.Show()
  49     app.MainLoop()

THE Easiest Implementation *Ever* :-)))

...no, really. All (most) of the above cases are one-way communication examples. Sometimes, you just want the main thread to be non-gui and communicate with the gui in a blocking manner. See http://radekpodgorny.blogspot.cz/2012/12/working-with-wxpython-in-separate-thread.html on how to achieve that.

/!\ update: robin was so kind to comment on my solution. i'll investigate all his ideas and probably refactor/improve the code. stay tuned and THANK YOU, robin! ;-)

Here is another helpful page on threading with UI elements, plus a nice implementation of decorators to help you out: https://python-forum.io/Thread-WxPython-How-to-deal-with-code-that-blocks-the-mainloop-freezing-the-gui

LongRunningTasks (last edited 2019-04-29 16:52:36 by RobinDunn)

NOTE: To edit pages in this wiki you must be a member of the TrustedEditorsGroup.