Hi! Back in 2009 I learned a tiny little bit of LV 5.1 and wrote 6 very simple VIs to read and write strings to 3 different hardware control DLLs:
The exported functions from the 3 DLLs are virtually identical. I write strings to the InputMsg of each DLL with a CString pointer, and it returns a BOOL success/fail. I pass a CString pointer and NumBytes into the OutputMsg, and it fills my string buffer and returns a BOOL success/fail.
All 6 VIs worked fine in 5.1, but when I attempted to re-created them in LV 2016, the PipatAuto library calls don't work. Regardless of how I set up the call, they return 0/FALSE, and the call doesn't actually do anything.
With the other 4 library calls to the other 2 DLLs, I can Send a string (such as "ID" or "STATUS"), and the Success indicator turns from 0 to 1. I can then Read a string, and I get the message from the DLL that I expect (such as "READY" or "No hardware found"), and the Success indicator turns from 0 to 1.
But with the calls to PiPatAuto.dll, neither Send nor Receive works. The Success/Fail indicator stays at 0/False, and there's no indication that anything has happened.
One possible difference with PiPatAuto.dll is that it's actually a wrapper DLL that calls the corresponding Automation functions in our MFC-based application (hence the name), whereas the other two DLLs are just faceless DLLs that directly export those Input and Output functions. Do I need to do anything different in this case? My C++ programmer is away on personal leave for another week.
The exported functions are declared, thus:
#ifndef PIPATAUTOEXP_H #define PIPATAUTOEXP_H extern "C" BOOL PiPatInputMsg(char* pMsg); extern "C" BOOL PiPatOutputMsg(char* pMsg,int nMaxBytes); extern "C" BOOL StartUpPiPat(); extern "C" BOOL ShutDownPiPat(); #endif
Solved! Go to Solution.
Are you sure that your MFC application that PiPatAuto.dll connects to, is properly installed and registered on your computer. From the name of the DLL it probably interfaces to the OLE Automation interface library (possibly Active X interface but could be also just a basic COM interface) and for that to work, the Automation server component needs to be installed properly on your system. It's unfortunate that your API only returns success or fail status without any further indication about what the problem might be if it failed. That would help when investigating such errors.
Ah, I think you're right. I just installed ancient LV 5.1 on this machine, and it also fails the same way.
I ran the 5.1 VIs on a system with a slightly older build of our software, and it works. So it's something recently broken in our software, and it appears to be independent of the LabVIEW version.
We dug a bit deeper, and the problem was UAC. We'd been confused by the different behavior on different machines, since we were using different logins.
If we log into the local machine as the named Administrator account, then the VI loads the DLL and launches the application just fine.
If we log into a different account, e.g. "Valued Customer", that has an Administrator account type, we can get it to work if we set the LabVIEW.exe executable to "always run as Administrator," except that we get the following error if we double-click a vi:
If we open the VI from LabVIEW, then we don't get that error.
So I still don't understand:
Since Windows 7 you have some privileged operations that even Admin account rights are not enough to perform, such as running any installation program. You need to be explicitly elevated. If you are logged in as Admin, you get typically an extra dialog prompt where you have to acknowledge that you want to do this operation. As non Admin user you get a login dialog that requires the Admin credentials to login as Admin and get into elevated mode at the same time. Launching a program as Admin also normally gives you these prompts and starts the program in elevated mode too.
Something in your application seems to require this elevated mode and that is definitely not LabVIEW specific.