Accepting button clicks (real-time) while processing OnClick event 3

[RetroKing]

I have written a custom search utility to allow users to find which data files from a repository of thousands of files that match their selected criteria. The user starts the search by clicking on a "search" button and the OnClick event for this button contains a loop that is used to process the appropriate files. I would like to add a "stop" button that the user could use to immediately terminate the search. However, it seems that additional button clicks are buffered and handled after the original OnClick event is finished. Any suggestions would be greatly appreciated.

I am using Borland C++ Builder Professional version 5.0. The application was created using File->New... and selecting "Application" under the "New" tab.

 

[2ffat]

The first thing that comes to mind is start a thread for the search. If a user selected the stop button, the search thread is stopped.

I would like to hear what others have to say, too.


James P. Cottingham
-----------------------------------------
[sup]I'm number 1,229!
I'm number 1,229![/sup]

 

[itsgsd]

2ffat is correct, creating a thread to handle the search would be a good approach, and is the approach that I would take.

There are other ways to handle this problem. The problem with executing sequential code such as a prolonged search is that while the application is processing the search loop, it can't detect and respond to messages. One approach is to allow the application to process messages during your search by calling Application->ProcessMessages();. The application can then detect and respond to your button's OnClick event.

So, if I have a global boolean variable StillDoSearch, the code in my search would be something like this:

while (StillDoSearch && SearchNotFinished) {

  // perform the next iteration of the search

  Application->ProcessMessages();
}

Then in your stop button OnClick event handler, all you need to do is set StillDoSearch to false.

If you decide to take this approach rather than creating a thread, however, you need to be careful since the application will respond to messages other than the stop button click which could have unintended results. For instance, you probably don't want another search to begin while a search is in progress.

Another approach would be to use a timer for processing a portion of the search at each OnTimer event, then the stop button would simply disable the timer.

 

[RetroKing]

Thank you for your replies.

I have done some searching on using threads and agree that this would be the nicest approach. Unfortunately, I have no experience with writing this type of code and in the time I spent searching was unable to find documentation geared toward someone learning it from square one. If you know of any tutorial style documentation on the subject I would greatly appreciate being pointed to it.

In the meantime, I used the approach involving Application->ProcessMessages() which works well. Thanks for the heads up on the application responding to other messages. I was actually able to use this to my advantage allowing the users to switch to other tabs of the application and continue working while the search is in progress but restricting them from changing the original search parameters or starting a new search.

Thanks again.

 

[itsgsd]

Learning to create and use threads is fairly simple,learning to make your code thread-safe is much more difficult and can require (depending on what the thread does) a fairly good understanding of concurrent programming concepts such as mutually exclusive access to shared resources, deadlock, livelock etc. Whole university courses are dedicated to these concepts alone. If you are unfamiliar with threads, I would expect that you are probably unfamiliar with these concepts as well. I don't want to discourage anyone from learning to use threads, multi-threaded programs are the only way to go for solving certain problems, and threads can be very powerful tools if used correctly, but I want to emphasize that it's not usually as easy as simply creating a thread and turning it loose.

I don't really know of any good web tutorials on threads, I'm sure you could search for them as easily as I can, but if you're interested, I remember a fairly good introductory tutorial in one of the C++ Builder books I have, I'd just have to find which one it is.

One additional point: You mentioned that by using the ProcessMessages() solution, the user is able to continue working while your search is still in progress. That really isn't completely true. One main difference between threads and the ProcessMessages() approach, is that the ProcessMessages() approach is a sequential rather than a concurrent or parallel approach, meaning that your program is really only doing one thing at a time. Any time your program responds to another message, your search is being suspended while it responds to that message and executes whatever code is associated with it. If that code happens to take a long time to complete, your search is interrupted for a long time. Once that code is complete, the search is resumed until another message comes along. In a multi-threaded approach, multiple threads of code actually are running concurrently (or at least sharing cpu time and system resources), so each thread can operate completely independently of any other thread.

I'm sure that's more than you were asking, but hope that some of the info helps.

 

[johncp]

There is a good intro. to threads using CBuilder by Jon Jenkinson, written for "The Bits", on the web as a PDF.
Google for

"The bits" threads builder jenkinson

and it comes up immediately