I want to use GetSystemTime SDK function in my application. But same function exists in CVI, and compiler says, "Type error in argument 1 to `CVI_GetSystemTime'; found 'pointer to SYSTEMTIME' expected 'pointer to int'." How can I use this function in SDK?
Thanks, aperez. I have CVI version 6. And I've figured out that if I do not include "utility.h" there is no problem to compile, but I need the Delay function(defined in utility.h), so I must replace Delay CVI API to sleep SDK API.
But how can I solve this problem if I MUST use function defined in utility.h ?
You're right. CVI also defines a GetSystemTime function. Here is the prototype of CVI's: int GetSystemTime (int *Hours, int *Minutes, int *Seconds); If you need to use Delay(), can't you use the GetSystemTime function provided by CVI? I don't think you can include both header files and use either GetSystemTime.
Hi! I solved this problem using GetLocalTime() instead of GetSystemTime. GetSystemTime returns UTC... Afterall, I still can not use GetSystemTime in SDK (although it is useless for me). I can not use GetSystemTime defined in CVI because I need to operate with respect to current time of millisecond order. Anyway, Thanks aperez for your kind consideration.
I went ahead and modified the NI utility.h header file to eliminate the NI GetSystemTime() prototype to solve this problem. That way I had access to the "real" (Win32) GetSystemTime() and could still access the remaining utility.h functions.
Why in the world did NI overload this well-known Win32 function with their own? It's not a cross-platform compatability issue - it only works on Windows!
Everyone keeps encountering this same stupid problem. That people keep wanting to use the Win32 function is firsthand evidence that the NI replacement isn't a viable equivalent.
Actually, it is not necessary to modify the utility.h file. You can just undef the GetSystemTime() function as follows:
#undef GetSystemTime
You should have the undef statement somewhere below the "#include " statement. This will allow you to use the Win32 GetSystemTime without our compiler thinking that you mean the CVI GetSystemTime.
On another note, CVI's libraries have been around for a long time (since 1988). This is not to say that our GetSystemTime has been around that long, but it probably has been around a very long time. It is not the first, nor will it be the last of our library functions that came into conflict with the Win32 SDK; specially because CVI predates the SDK.
Be that as it may, users repeatedly run up against this issue, and waste a lot of time trying to resolve it.
Perhaps it would behoove NI to add a switch or option to defer to equivalent SDK calls when there's a conflict. Or at least document the problem more clearly. After all, you're promoting CVI's ability to use the Win32 SDK.