Reputation: 68074
I'm trying to do 'pre-flight checks' by testing a COM port's 'openability' before launching a dialog window which allows the user to do com-porty things.
Here's the code sequence, in outline:
handle = CreateFile("\\\\.\\COM4:", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,NULL);
if (handle != INVALID_HANDLE_VALUE)
{
CloseHandle(handle);
DoTheWork("\\\\.\\COM4:");
}
else
{
ShowMessage("I'm sorry Dave, I can't do that");
}
...
void DoTheWork(char * port)
{
handle = CreateFile(port, GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,NULL);
/// do lots of stuff
CloseHandle(port);
}
Here's the problem: "DoTheWork" is a tried and tested function, and performs correctly on it's own. It only fails when called immediately after the earlier CreateFile/CloseHandle calls, when the second CreateFile returns E_ACCESSDENIED.
Worse yet, if I step through the code slowly in the debugger, It works just fine.
It seems like I need a Sleep() after the first closeHandle, but that feels like a hack - and i have no way of knowing how long it must be.
Upvotes: 1
Views: 2722
Reputation: 8216
Try calling PurgeComm() or FlushFileBuffers() on the handle before closing it.
Upvotes: 2
Reputation: 68074
Well, after more trawling, I found this, which relates to Windows CE rather than Win32.
There is a two-second delay after CloseHandle is called before the port is closed and resource are freed.
I guess the same applies to Win32, but I haven't found any documented proof.
Upvotes: 0
Reputation: 22502
The system takes a bit of time to close the resource. There's probably some arcane way to test whether it's been freed, but I don't know what that is. What I do know is that if you check the registry key:
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM
You'll see which serial ports are available without having to open them, which should solve your problem.
Upvotes: 2