Processing Windows Messages

Every thread that creates a window must process Windows messages to avoid causing your system to lock up. The User Interface Library RunUserInterface function contains a loop that processes LabWindows/CVI user interface events and processes Windows messages. The User Interface Library GetUserEvent and ProcessSystemEvents functions process Windows messages each time you call them. Each thread in your program must call GetUserEvent or ProcessSystemEvents regularly to process Windows messages if either of the following circumstances is true:

• The thread creates a window and does not call RunUserInterface.
• The thread creates a window and calls RunUserInterface but executes callbacks that take a significant amount of time (more than a few hundred milliseconds) before returning back to the RunUserInterface loop.

However, there can be places in your code where it is not appropriate to process Windows messages. When you call GetUserEvent, ProcessSystemEvents, or RunUserInterface from a LabWindows/CVI user interface thread, that thread can call a user interface callback. If you call one of these functions in a user interface callback, the thread might call another callback. Unless you have planned for this, this event might generate unexpected behavior.

Utility Library multithreading functions that cause your threads to wait in a loop allow you to specify whether to process messages in the waiting thread. For example, CmtWaitForThreadPoolFunctionCompletion has an options parameter with which you can specify that the waiting thread processes Windows messages.

It is not always obvious when a thread creates a window. User Interface Library functions such as LoadPanel, NewPanel, and FileSelectPopup create windows that you display and discard. These functions also create one hidden window for each thread that calls them. This hidden window is not destroyed when you discard the visible window. In addition to these User Interface Library functions, various other LabWindows/CVI library functions and Windows SDK functions create hidden, background windows. To avoid causing your system to lock up, you must process Windows messages in threads that create windows in either of these two ways.