LabVIEW
Windows Message Queue 64-Bit Support
The thing is that I must be able to detect the main thread closing from inside the DLL.
The reason for it is that otherwise the VI handling the windows messages (the one below) will stand there waiting for a message even when I'm going to close my application. I'd like to close it in a cleaner way instead of letting LabVIEW clear the DLL.
since I need just to check for USB removal or the application closing is it your advice to pass the reference to the LVFrame instead of my main window? in that case wouldn't it be sent only when LV is going to close in any case (when it has already freed the DLL)?
@madview wrote:
since I need just to check for USB removal or the application closing is it your advice to pass the reference to the LVFrame instead of my main window? in that case wouldn't it be sent only when LV is going to close in any case (when it has already freed the DLL)?
Well, how the actual windows messages are exactly sent and when and by whom is beyond LabVIEW's control and LabVIEW certainly doesn't need to send itself a windows message WM_QUIT if it wants to shutdown itself so there is no guarantee that such a message ever arrives in the LVFrame window. The windows message queue is how LabVIEW interfaces to Windows, since Windows requires this from any GUI application that wants to run on Windows. There is no alternative to this. The LabVIEW implemented callback function simply translates those Windows messages to internal messages and sends that then to the LabVIEW native window proc that is on all LabVIEW platforms the same. When LabVIEW wants to shutdown itself it simply sends that native message directly to its own windows and doesn't need to first generate a Windows message to be sent through the Windows message queue, to then be translated into a LabVIEW native message and then handled.
What is documented and known is that before LabVIEW wants to quit, be it because it received a WM_QUIT message from Windows or because you selected the Quit command in the LabVIEW menu, it calls all event structure cases with the Application instance Closed? filter event. If none of those event frames return with a Discard? = True status, it cleans up whatever it needs to clean up, then calls again all event structure cases with the Application Instance Closed event as a last chance for any code to do its own cleanup and then it goes unloading all VIs and eventually all DLLs too and then it simply terminates.
So if you insist on detecting WM_QUIT or similar events to detect that you need to close all resources in your DLL you will likely never detect when a user selects the Quit menu command, as it makes very little sense for LabVIEW to send itself a WM_QUIT command that then needs to be translated again and processed. If you absolutely want to properly cleanup in the DLL itself the right place to do so is in the DLL_PROCESS_DETACH case in the DllMain function. But do never try to call LoadLibrary() and FreeLibrary() ever in that function! It very likely will cause a Windows loader lock that can only be resolved by killing the process.
But this DLL already does that and the only other resource that is used, is the EIL EventInfoList, but that is a static variable of a standard template list object, for which the C++ compiler automatically generates according prolog and epilog code to allocate it on module initialization and deallocated it on module unloading, so your entire worrying is pretty unnecessary.
