This is a classic problem with GUI based applications.
GUI events are processed on the same thread as loaded the GUI panel. So, if you have this thread off doing something, isn't processing GUI events and your STOP control is unresponsvie.
So you could:
1. Whenever you have the GUI (usually the main) thread off doing something, have it periodically make a ProcessSystemEvents() function call so as to be able to respond to a GUI event and execute your STOP control callback function.
2. Create a "worker" thread to go off and do the operation, leaving your main thread available to process GUI events i.e. RunUserInterface(). When the user wants to STOP, the main thread see it quickly, and signals the worker thread(s) to stop or even terminates them directly. This is the most common design pattern for this problem.
3. Create a separate panel with the STOP control on it, load this panel from a secondary thread, and then have this secondary thread loop on checking the control state and reacting to it when the STOP control is used. You have to be careful not to simply spinlock on the control state check so as to not consume lots of CPU bandwidth. I have used this with a high-priority thread doing the monitoring,sleeping most of the time but waking up every 100 msec or so to check and see if the STOP control has been clicked. Once it has, you can have this second thread safe the test system (watch out for resource contention), or it can signal the main thread to stop (but this sort of begs the question) or it can try to exit the process. You have to be careful that the process termination quits when you think it does, it's possible to deadlock an ExitProcess() call. You can use TerminateProcess() or ExitProcess(), but you should educate yourself on the differences between these two functions.
The Windows threading model accomodates "user interface" threads that process GUI events off the message queue as well as "worker" threads that don't. But, the CVI event model doesn't provide this distinction.
