DLL causes error when quiting LabVIEW 2009 on WIN7

[RealBjörkis]

Hello,

I have reduced the problem in my EXE application to the following attached code (see attachment). Somehow the DLL (To User32.dll) calls are creating a problem when quiting Labview 2009. The Application stays resident in the Windows taskbar and after a while an error appears about that there was a problem closing the application and that it can be reported to Microsoft if desired. Then a second error message appears before the application dissapears from the taskbar. If I remove the DLL:calls from the code then the problems dissapear.

Should I unload the DLL calls on a special manner before quiting LabVIEW?

[muks]

see here

[rolfk · Accepted solution]

Another potential problem not mentioned in that article is that you have included your user32.dll explicitedly in your built application. Doing that creates 200% for sure trouble as the kernel32.dll, user32.dll and others are always residently loaded into memory anyhow and mapped into the system memory section of any process. If you tell an application to load this DLL again by explicit name, you end up having two copies of it mapped in your process memory space and that will cause very weird problems.

To avoid this problem make sure the library name inside the Call Library Node only specifies the DLL name without any path information. Then close the dialog and save it. If you reopen the dialog it will show the full path but still save the name only until you make a modification in the path control at which time you can end up having a full path again.

[RealBjörkis]

Thanks Rolf!

That really did the trick. I had been using the keybd_event in user32.dll and even the Sendinput command (which replaces the keybd_event in newer versions of the dll) with no result. I also downloaded "Util.WinAPI_Tool.SendString.EXAMPLE" from the forum and used pretty professional code from there but still the error appeared.
Nevertheless when I made a test using GetCursorPos from the user32.dll and using the full path the program quited without any errors. Perhaps reading info from the user32.dll is less conflictive.

Another thing I noticed when reopening the Call library node dialog after saving the VI and only put the dll name there, is that only the name was there. The path hadn´t come back according to what you wrote.