Hello CVI-User,
All UI functions are supposed to be thread-safe.
Having said that, I did run your program and was able to reproduce the crash. After some investigation, I was able to find the underlying bug in the CVI runt-time engine that is causing this crash. We'll fix this bug in the next version. Unfortunately, there is no good way that I can think of for you modify your program in order to avoid this bug. The bug can happen when you set or unset the modality of a panel from a secondary thread.
The longer explanation for the bug is as follows:
The UI library implements its thread-safety, for the most part, by locking all functions and event processing at the highest possible level of the API. This ensures that at any one time, only one thread is active inside a UI function. That is the theory. In practice, things are a bit more complicated. Because there are a number of Windows system calls that result in messages being sent to other threads, in order to avoid deadlocks, the global UI lock sometimes has to be temporarily relinquished, which can allow another waiting thread to enter a UI function. When this happens, a "hole" is created, and special code needs to be written to patch up this hole manually. Unfortunately, you've run into a hole that hadn't been detected before, and therefore hadn't been patched. What is happening internally is that the main (RunUserInteface) thread, in response to an application activation message, is relinquishing a lock around a required low-level operation on one of the two windows that belong to the thread functions. Sometimes, when that lock is relinquished, one of the the other threads enters the HidePanel function. Normally that would be a harmless operation, but when the panel is modal (created via InstallPopup), that requires the panel's window to be replaced (destroyed and recreated). When the timing is really bad, the old window is destroyed just before the main thread tries to access it, and the crash ensues.
Let me know if you have any other questions.
