Indeed, using the parent widget "update" method after any text insertion (or any graphical change to the GUI for that matter) ensures that progress messages are delivered in time.

It also makes the GUI somewhat responsive. Now, most of the time, an update call will be reached every two or three seconds. So, if the user wants to abort and press the exit button, it will exit within a couple of seconds. It's still not very elegant, but this is way better than having to wait for the entire computation to be done before the "abort" command is executed! If this is the best way to keep the GUI responsive without using parallel programming, I will be very happy to take this route.

But I still see a problem with this solution, so I would like to submit it to the eyes of the Monastery. The remaining problem is: whether it takes 0.1 seconds or 10 seconds between two update calls depends upon the user's input files. That's because the time it takes for a chunk of code to execute (and hence, the time it takes between two update calls are executed) depends on the nature of the input. Can you, monks of the Monastery, think of a way to make update calls at fixed time intervals (let say once or twice per second) even though I have little control on the time it takes to execute a chunk of code?

Thanks again for your help! It is very appreciated!