LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Updating controls from second thread

I have read that in win32 you should not access ui controls created on a second thread as your program can hang or crash.

An example of which is http://www.yoda.arachsys.com/csharp/threads/winforms.shtml

Is this the same for CVI ?

Ie you should not call any method such as SetCtrlVal , SetCtrlAttribute etc
from another thread whether it is from a thread pool or async timer.

I ask because I see prevoius messages posted here about threads that show this being done and I wanted to comfirm you should not.

Regards

Glenn
0 Kudos
Message 1 of 3
(3,223 Views)
The CVI User Interface Library is multithread safe and allows you to call most functions from multiple threads. This includes calling SetCtrlAttribute, etc from multiple threads to access the same control. There are some caveats, like DiscardPanel should be called from the same thread that called LoadPanel for that particular panel, etc. These exclusions are noted in the various UI functions' documentation.

But I personally feel it is a good design practise to restrict as much UI operations as possible to the thread that owns the affected window (CVI panel). For example, if a program has two threads, one performing UI updates and the other performing, say, TCP communication, then I think the TCP thread should defer to the UI thread for more complex UI operations rather than calling these routines itself. The PostDeferredCallToThread function in the Utility library is useful for this. Of course, one can also use other signalling mechanisms to achieve this.
0 Kudos
Message 2 of 3
(3,206 Views)
In case you are wondering, this is possible because CVI controls are not native Win32 controls - they are implemented completely within CVI. But CVI parent panels are Win32 windows. Also, if you are using ActiveX controls on your panel, then you should follow the rules of ActiveX and that particular control - which in almost all cases would restrict the control to be accessed only from the thread (or threads that belong to the same COM apartment) that created it.
0 Kudos
Message 3 of 3
(3,203 Views)