> The whole point of using threads is to allow the main thread to continue
> moving forward while the thread is working in the background. But since you
> are trying to reset the cursor immediately it seems that you are expecting
> the calling thread to not move forward until the background job is done.
> Regardless, you should not do anything in the background thread that
> directly interacts with the UI.
Well, maybe I'm going about this the wrong way. Putting this in terms
of the user experience, I thought it would be good to have the
following conditions:
1) While the numbers are crunching (up to a minute or more), the
cursor is an hourglass, to mean "please wait and don't bother to do
anything, we're not done".
2) But, so that the user doesn't wonder whether the program has simply
crashed and is never going to finish (which had happened in earlier
versions with my client), I thought it would be great to keep the GUI
updating the user on the status by writing text about which file is
processed. (Thus using a worker thread so as to not block the GUI
thread).
3) Then, when it's all done, the hourglass returns to the arrow cursor
to mean, "Now you can click on the 'See the results' button if you
want.". In fact, this is complementary to the other UX point of the
text saying, "Files processed!".
I would think this is the default approach in the GUI world, and
updating the cursor once a number crunching thread is finished should
be trivial.
Does that make sense? Sorry to draw this out, but it's more about the
learning point for me more than even this program (in that the cursor
is not that crucial at all). Thanks again!