03-16-2023 03:32 PM
Okay. This gets around all of the issues...
extern "C" __declspec(dllexport) float __stdcall GetIdleTime()
{
LASTINPUTINFO lii;
lii.cbSize = sizeof(LASTINPUTINFO);
if (!GetLastInputInfo(&lii)) {
return -1.0f; // error getting last input info
}
DWORD idleTime = GetTickCount() - lii.dwTime;
float idleSeconds = (float)idleTime / 1000.0f;
return idleSeconds;
}
03-16-2023 03:44 PM
So you created a dll that calls the libraries in the windows folder?
What was said for kernel32.dll also holds for user32.dll (and all the other system dlls in system32 and other places): do not use paths for system libraries, only their name.
03-16-2023 06:16 PM - edited 03-16-2023 06:18 PM
@david.fox wrote:
Rolf,
The NI Tick Count is great and useful. But this application is to monitor keyboard/mouse idle time. If there is another way to do this, I would be more than happy to hear about it. As of now though, it appears the kernal and user32 is all that is able to count this for me.
I did not suggest to use the Tick Count (ms) node but Jim is absolutely correct. This node is in fact nothing more than a simple call to kernel32:GetTickCount(). So for this function at least you win ABSOLUTELY nothing by calling the Windows API, other than additional potential trouble.
And I DID describe how to solve your problem. Read my post again! user32.dll or kernel32.dll does not matter, either of these will crash if it is loaded as private copy. Not with every API function but sooner or later it will absolutely and surely crash.
03-17-2023 04:41 PM
@david.fox wrote:
Rolf,
I have immense respect for him and his forum presence, but, flattered as I may be, I sadly cannot claim to be Rolf.
@david.fox wrote:
The NI Tick Count is great and useful. But this application is to monitor keyboard/mouse idle time. If there is another way to do this, I would be more than happy to hear about it. As of now though, it appears the kernal and user32 is all that is able to count this for me.
I have no idea why you think what the application is for is relevant. Perhaps you misunderstood, but my point was that it is literally the same Windows API call. There is no difference using LabVIEW's Tick Count function aside from it being easier and avoiding these misconfigured Call Library Nodes.
If you want to write another DLL and add a dependency to your app that requires an additional toolchain, feel free. However, this error I got opening the snippet you posted sums up your problem.
You CANNOT copy Kernel32.dll to another location. It should not be expecting to load from your data folder. Likewise, this is also wrong:
That works in the IDE, but using the full path causes the Application Builder to believe this is a private library that should be copied to your build path. That is why it breaks when you build an EXE.
The correct way to reference a DLL that is part of the Windows system is simply this:
I think if you try the attached version, you will find it works both in the IDE and when compiled to an EXE. If you try the second version, I think you'll notice very little difference in the result.