| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > 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 - может отчасти помочь |