FileSelectPopup hang with restrict extension option and imaqGetFilterNames(..)

[tstanley]

Hi,  I'm having a problem with FileSelectPopup hanging.  It happens when I restrict the file extension in the pop up, and the user types in a name with a different extension (for example, if I restrict the file extension to "*.dat" and the user types "data.txt").  This causes the "File extension limited to ..." pop up, I get a wait cursor, and I can't click on anything to make the pop up go away which effectively hangs the application.  This happens both on the deployment PC as well as my development workstation.  If I'm in the debugger hitting the stop button shows that the program is in the FileSelectPopup(...) function.  Curiously, so far I'm only seeing this on Windows 7 PCs (64-bit, Professional) while the Windows XP PCs (both deployment and development) do not yet shown this.  

After some time, I managed to track it down to the imaqGetFilterNames(..) function.  If I call a FileSelectPopup(...) before I call the imaqGetFilterNames(..) function then it behaves correctly.  If I call it after I call the imaqGetFilterNames(..) function then I get the hang.  I've attached a sample application.  To see the issue, click the "Get Filter Names" button, then click the "Generate FileSelectPopup" button, and enter a file name with a different extension than allowed such as "data.txt".  If the "Get Filter Names" button is not clicked first then the FileSelectPopup behaves normally.

My development PC is running CVI 2010 SP1 10.0.1 (419).  I have NI-IMAQ 4.6.1, NI-IMAQ I/O 2.5, NI-IMAQdx 3.9.1, NI Vision 10.0.  Windows 7 64-bit Professional.

Thanks in advance for any help or pointers.

[MilanR]

Hi tstanley,

This is interesting behavior and I was able to reproduce the same behavior by running the attached source with the provided instructions. It looks like the call to the imaqGetFilterNames() function is possibly locking the UI thread in CVI but I'll have to look a bit closer to see what is happening

[tstanley]

Hi,

Thanks for the reply and looking into this.  Let me know if you find anything out. 

[D_Biel · Accepted solution]

This is a problem with the apartment threading style. As is described here on MSDN, using an multithreaded apartment model can cause problems with the Windows file dialogs. The FileSelectPopup function is essentially a wrapper around the windows file dialogs that help you configure the various settings. So if you are using a multithreaded apartment model, you may run into issues whenever using the CVI FileSelectPopup or any of the other Windows file dialogs. Typically, your application will only get set to multithreaded apartment if you make an ActiveX call, because all of the functions in the CVI ActiveX Library initialize the threading model to multithreaded apartment. I am not familiar with the vision software, but I suspect that they are making an ActiveX call themselves or in some other way initializing the threading model to multithreaded apartment. So in order to avoid this hang, you simply need to configure the threading model to single threaded apartment before calling the IMAQ function; at the beginning of main( ) is a good place. Once the threading model has been initialized, it is set in stone and cannot be changed. That is a good thing here because it will prevent the IMAQ function from changing it to multithreaded apartment.

Add the following to the beginning of main( 😞

CA_InitActiveXThreadStyleForCurrentThread (0, COINIT_APARTMENTTHREADED); 

[tstanley]

Hi Milan & D Biel.   Thanks for the help. I tried adding that line of code in my application and it solved the problem.  I'll have to look into why it works so I can understand better what's going on.  I take it that this is something that'll have to do moving forward in applications that use the IMAQ (and possibly other) libraries?