Real Software Forums

In reading about threads, the documentation states: "NOTE: Manipulating the UI from within a thread is not recommended and in fact is prohibited in newer versions as it can cause serious issues: application hangup, crashes... There are better and safer ways to achieve such goal."

Then, the example goes on to show how code executed within the thread can update the contents of a listbox while allowing the user to scroll through the listbox.

It seems that I want to use a thread in a couple of my applications - pretty much doing what the example shows. Probably filling a listbox from a large file while the main process keeps a progress bar going.

So... What's with the warning about about not manipulating the UI from within a thread ?

Ron Bower
Ellicott City, MD

See http://www.realsoftwareblog.com/2012/05/doing-progress-right.html

Thank you for that link - the Blog is very informative and I have bookmarked it for later reference.

I've tried an architecture with code very close to that described in the Blog article. Here's a brief summary of my specific situation and what I want to do...

I have a program that may sometimes involve reading or writing large files into or from a RealSQL Database. In extreme cases, the process can take 30 seconds or more and the user may lose confidence that the operation is still in progress.

So, in my first attempt, I put all the read/write code into two separate thread's RUN procedure. Then called the thread to execute the procedure. That seems to work fairly well - certainly the best of any other way I have tried.

However, here's the snag - I don't want the user to do anything until the file has been loaded or saved. That is, essentially I want to suspend the application's main thread and resume only when the spawned thread completes.

But... I have not found a way to suspend the main thread. So, all I could do is to implement a While loop that looped until the thread status indicated that the thread had completed. Implementing that While...Wend loop however, just created a busy CPU-user that competes with the spawned thread for CPU time.

So I am caught in this dilemma:
>> If I try to read and write the file as a process in the main thread, then I can't display and update a progress bar as I'd like - precisely for the reasons that you have described.
>> But, if I spawn a process thread to execute the read/write, then I need to somehow pause/sleep/wait the main process until the thread completes.

Is there such a thing as a sleep(), wait(), pause(), wake_on(), or any other signal that I can use to make the main process wait for the spawned thread to complete ?

Thanks to all for any help/advice you can provide.

Ron Bower
Ellicott City, MD

Open a modal window informing the user to please wait.

While that seems like one solution, I'd really like to find something more elegant.

In most ( 99% + ) cases, the file read/save operation takes less than a few seconds - not enough to worry about and I'd just hate to have to put up a modal window with a "Wait" message and a "Close" button that the user would have click on every read/write.

Besides, in worst case when the read/write is taking a long time, there's no guarantee that the user would not just close the modal window and gain access to the UI while the thread is still executing.

Ron Bower
Ellicott City, MD

don't put a close button on the "wait window".

open the window
perform your task
close the window

there should be no need for any user intervention


for that matter.... move the database task TO that window

although personally I would just disable the current window and display a "wait" label instead of a whole new window....

The main point is that pausing or blocking the main thread is a bad idea. It just puts you back into the situation where the app looks like it's hung. You need to keep the UI active, but not allow the user to actually do anything.

Along the same lines of Dave and Tim; create a procedure you can call to enable or disable "accessing" the main window (i.e. enables/disables the UI components - greys them out). When the user asks for the database access routine (say button click to process file), you can start a timer, disable the UI components, and start the thread; the timer can periodically check the status of the thread and update the progress bar (sort of like the blog suggests). When the thread completes; the timer can re-enable the UI. I always like to keep a button on the main window from which you can stop the thread if the user so chooses.

Thanks to all for all the advice... I think I have the thread running the way I want it now.

Ron Bower