LabWindows/CVI
Calling GetLastError returns 0 for CreateFile function
@Dany80 wrote:
I have the folowing code:HANDLE hTemp = NULL;
DWORD dwERR = -1;
char szComPort[20] = {0};
sprintf(szComPort, "\\\\.\\COM%d", 2);
hTemp = CreateFile((LPCSTR)szComPort,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
if (hTemp == INVALID_HANDLE_VALUE)
dwERR = GetLastError();
The code was tested on LabWindows Cvi 8.1.
COM2 doesn't exist on my PC so i get an INVALID_HANDLE_VALUE from CreateFile function.
But calling GetLastError i always receive 0.
Running the same code on a visual C i get the result 2.
How can i get the error code from LabWindows CVI?
I tested GetLastError on some other Windows API functions in CVI like SetCommTimeouts,SetCommState with bad handle values .
The result was always 0 from GetLastError.
Is this a general problem in CVI.
Threading issue? Last Error in Windows is maintained on a thread base. So if your code executes in different threads that could be a problem. Or if you don't use other threads LabWinddows may still do some intermediate internal "multi-tasking" calling other Windows API functions that could influence last error??
Rolf Kalbermatter
@jr_2005 wrote:
The error codes are maintained on a per-thread basis, so it is not possible for a separate thread to alter the value. It is most likely that the debug framework code that CVI inserts around your statements is to blame. As long as you get the correct results in the Release build, I guess it does not really matter?
JR
It's not only possible but unavoidable. In order to single step CVI has to update the screen and that involves numerous Windows API calls some of which influence the last error code. Sure CVI could try to save all these state informations after each debug breakpoint and restore them again when continuing, but there are many of such variables, some thread specific, some task specific and some system wide and also it wouldn't always guarantee that not other operations could still influence such variables, so why worry if you can not likely make it perfect but use quite a bit of performance for that too.
Rolf Kalbermatter
@jr_2005 wrote:
Rolf,
You appear to be have misunderstood me. I quote directly from the Windows SDK help topic on GetLastError() :
- The GetLastError function returns the calling thread's last-error value. The last-error code is maintained on a per-thread basis. Multiple threads do not overwrite each others last-error code.
I agree that it is the CVI debug framework that is most likely calling a routine somewhere that is clearing this error flag, but this will be in the same thread as the code being debugged.CVI debug puts a lot of stuff around user code, which clearly executes in the user's thread. (As well as other debug code which runs in different threads, of course.)
I don't think I misunderstood you.
Apart from that CVI does put a lot of things in debug mode to the code and executes it too; unless they changed that in recent versions, if you don't make specific provisions I didn't think your CVI code is multithreading by default. They could of course execute UI updates always in a separate thread but that could be slowing down specific code more than letting the UI update run in the callers thread. But heck they do this all the time for LabVIEW so maybe they use it in CVI too, but not sure that is the case by default.
The fact that last error does seem to be cleared only in debug mode does certainly indicate that it has something to do with debugging but if that is screen updates of the editor window etc. or just some debug framework code I couldn't say.
Rolf Kalbermatter
