Does FileSelectPopup() create thread that is not cleared?

[CviUser2003]

When my users are using my application, they notice some threads that are created and not destroyed. I could only explain it as CVI having some underlying code that creates it because my code does not use CreateThread() in those instances.
1) when menu is selected (not clicked on, just if menu bar is activated)
2) when LoadPanel() is selected
3) when FileSelectPopup() is used.

I guess I understand why (1) and (2) create threads that do not get cleared, but why doesn't the thread for FileSelectPopup() get cleared after I use it?

Attached is a sample app that shows (1) and (3). I tested it by using TaskManager. Look at application,
- 1 thread is active upon initialization.
- When
menu is selected, there are 3 threads active.
- When (untitled) button is pressed, there are 7 threads active (sometimes 6).

I wait for a while, sometimes only 5 threads are active, but it never goes back to 1 thread.

What can I do to terminate those threads, so my users don't think I have a runaway thread causing them their thruput issues?

[bilalD]

Hello

This looks more like a property of system rather the way CVI does it. I noticed the same behavior in VC++ as well when I called the file dialog API thru the SDK. I used TaskInfo to monitor this, and the additional threads created never use any resources and they're all in a wait state so I doubt these threads would affect performance in any way.
Plus its never really a good idea to forcefully terminiate a thread, since the thread might not clean itself up properly if you just shut it down.

The threads should do their own cleaup once the application exits.

Hope this helps


Bilal Durrani
NI