LabWindows/CVI Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
blakney

Recode FileSelectPopup, MultiFileSelectPopup, DirSelectPopup (and extended variants) to be unaffected by the MTA setting of the current environment.

Status: New

If the thread that FileSelectPopup (and similar) is accessed is multithreaded, wacky things happen. The programmer can fix this by creating a new thread that is itself not multithreaded and pass information back to the current threrad. It would be helpful if the current functions were designed to default to create such a thread,  return the value(s), and garbage collect removing the programmer from the loop.

 

In the case of MultiFileSelectPopup, it is not clear to me what would be the best practice given the unknown number of results. I guess one could assume a limit for the number of results that may change as the Windows API does.

 

Other possible solutions can include an added parameter (variable switch) or with a whole new function. I could see the default case as an effective solution for legacy code that is partially refactored for multithreaded performance.

1 Comment
Wolfgang
Trusted Enthusiast

I think this is a brave and important suggestion...

 

Yes, the help mentions that FileSelectPopupEx and friends do not work properly in MTA, but since FileSelectPopup etc. have been superseded and since it would be strange to display a Windows XP style dialog in Windows 7 the new function should work without quirks...