Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > C/C++: Системное программирование и WinAPI > Проверить валидность дескриптора |
Автор: deniska 22.6.2010, 12:19 |
Всем привет. Ситуация: есть некая железка, подключается к компу по USB. при подключении железки к компу, ее драйвер создает виртуальный ком-порт. проблема вот в чем: допустим железка подключена, я открываю порт, общаюсь с устройством и вдруг, допустим железке вырубают питание/выдергивают шнурок/бьют по ней кувалдой, короче устройство из системы исчезает и мой дескриптор порта становится невалидным и соответственно ошибки, ошибки, ошибки. как можно проверять валидность дескриптора? (открывать порт на каждую команду а затем закрывать его - долго) |
Автор: Abyx 22.6.2010, 13:00 |
GetLastError ? |
Автор: deniska 22.6.2010, 13:31 |
GetLastError где? при очередной WriteFile\ReadFile просто возникнет Access Violation. или не возникнет, но чего сделает - непонятно... |
Автор: dumb 22.6.2010, 15:00 |
не совсем ответ на вопрос, но может отслеживать usb-шные уведомления? |
Автор: deniska 22.6.2010, 15:43 |
думал об этом, но тут просто вопрос архитектуры приложения.... не хотелось бы в класс железки это внедрять. но естественно, если API средств не найдется для проверки - естественно придется через них, и потом не факт что винда меня уведомит об отключении устройства раньше, чем я попытаюсь записать\считать так как процесс обмена с устройством в отдельном потоке. короче надо пробовать если иных способов нет |
Автор: deniska 22.6.2010, 17:07 |
если система после отключения устройства успеет переназначить дескриптор\память для чегото другого - будет ошибка доступа, не успеет - не понятно что будет. на моих опытах - 100% ошибок доступа. только какой смысл представлять что случиться - главное что неслучиться того что было нужно а именно - записи\чтения |
Автор: xvr 22.6.2010, 17:50 |
Хэндл не становится невалидным из за того, что выдернули устройство. А вот работать с ним система может и отказаться, но не из за того, что он невалидный, а из за багов в драйвере ![]() Попробуйте SEH (__try __except) вокруг FileRead/FileWrite - может отчасти помочь |