Rif.: Spurious combase messages using FileSelectPopupEx

[Sparhawk]

Hi,

Hope someonecan help. I’m trying to use a File Select Dialog in LabWindows\CVI 2020 using the FileSelectPopupEx(…) and I keep getting the following error appearing in the DebugOutput window:
 
                onecore\com\combase\dcomrem\security.cxx(3071)\combase.dll!75A16ACD: (caller: 7BCC7E3A) ReturnHr(1) tid(4624) 80010117 Call context cannot be accessed after call completed.
 
What is causing this? I don’t think it’s a threading issue as I’ve created a simple test app that only displays a panel with a button to create the dialog and nothing else. I also added 'CA_InitActiveXThreadStyleForCurrentThread (0, COINIT_APARTMENTTHREADED)' to the start of the function and it made no difference. The Dialog seems to work fine regardless however I’m not happy to simply ignore it as there maybe something wrong for it to be generated! This also happens if I use example code uirview.cws on the FileSelectPopupEx help page.

Cheers,

Calum

[carlox · Accepted solution]

Simply ignore them, your code is fine.

They are internal messages coming from  Windows system DLLs and the messages are trapped by the current OutputDebugString() target, i.e. the LabWindows IDE. 

NI people could filter them out, just to avoid this pain, but I doubt that such cosmetic issue will be ever considered.

[Sparhawk]

As a matter of interest I logged this issue with NI Support and it is being filed as a bug report, albeit at a low priority so it may be resolved! The full report from the engineer looking into it for me is:

"CVI uses Microsoft standard functions for OpenFile and SaveFile from the Windows SDK; this is where the suggestion of the alternative thread comes from, as this is actually direct from Microsoft page recommendations.

FileSelectPopupEx (and FileSelectPopup) both then track into the Microsoft API for the error handling. The Windows SDK OpenFile function returns “RPC_E_CALL_COMPLETE”, which in CVI translates to the error we see in the debug output. This is occurring on the initialisation/de-initislisation on the function. This then reports down to an error that should be handled by CVI as a 0-severity warning, but is instead producing the debug output we see.

Essentially – that is an expected response from the Windows SDK that CVI isn’t parsing correctly in this scenario, and so creates a debug output that isn’t accurate to the severity of the situation. It’s an output that we can safely ignore.

I’ll file a bug report internally about this but at a low priority, as this isn’t breaking anything; just providing a warning that the call has finished as expected that LabWindows/CVI isn’t parsing correctly."