Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[pastor]

Потому что если открыть порт и выдернуть его - то из этой ветки устройство не исчезнет! На crossplatform.ru уже обсуждали.

Интересно, никогда не наблюдал такого. Кинь ссылку на топик.

[kuzulis]

Тут: http://www.forum.crossplatform.ru/index.php?showtopic=3012&hl=SERIALCOMM&st=40
см. начиная с поста №44 и далее.. №56 и т.п.

[Hvzh]

kuzulis,

Попытался скомпилировать Вашу библиотеку под Виндозой используя MSVC 8.0. Компайлер споткнулся на файле nativeserialengine_win.cpp вот на этой строке:

   

Код:

 if (::WriteFile(this->descriptor, (PCVOID)data, (DWORD)len, &writeBytes, &this->oWrite))
 

Ему не понравился PCVOID. Все скомпилячилось после замены на LPCVOID. Как я понимаю, PCVOID - это приблуда mingw, для мелкософтовских компайлеров неприемлимая

[Barmaglodd]

Абсолютно точно надо через создание окна ловить события. Сам делал так (правда через QWindow и winEvent), т.к. с QWinEventNotifier (в вашей старой реализации ) периодический access violation в недрах системы обработки событий Qt при извлечении устройства. К тому же такая реализация проще для понимания, а в QWinEventNotifier чёрт ногу сломит.

[kuzulis]

Ему не понравился PCVOID. Все скомпилячилось после замены на LPCVOID. Как я понимаю, PCVOID - это приблуда mingw, для мелкософтовских компайлеров неприемлимая

Ок, исправлю.

Абсолютно точно надо через создание окна ловить события. Сам делал так (правда через QWindow и winEvent), т.к. с QWinEventNotifier (в вашей старой реализации ) периодический access violation в недрах системы обработки событий Qt при извлечении устройства. К тому же такая реализация проще для понимания, а в QWinEventNotifier чёрт ногу сломит.

Наоборот, через QWinEventNotifier  проще!
Тем более, QWinEventNotifier  используется в AbstractSerial для уведомлений для сигналов readyRead, dtrChanged и т.п.

периодический access violation в недрах системы обработки событий Qt

так нужно смотреть от чего это.

Я что то передумал что-то менять QWinEventNotifier на WM_blabla, т.к. всё-равно WM_blabla - это костыль (ИМХО).  
Понятно, что если отказываться от приватных методов, то заменить в классе SerialDeviceEnumerator  на WM_blabla в принципе можно, НО
не чем заменить QWinEventNotifier в классе AbstractSerial!

Мда, дилема.

[Barmaglodd]

так нужно смотреть от чего это.

Я уже не найду этот код.
Вспомнил, я уже писал об этом http://www.prog.org.ru/index.php?topic=9537.msg65014#msg65014

чем заменить QWinEventNotifier в классе AbstractSerial!

Я заменил на поток, блокирующий IO и поллинг. Но это для моего узкого случая.

[kuzulis]

Я заменил на поток, блокирующий IO и поллинг. Но это для моего узкого случая.

Допустим 20 ком портов, тогда придется создавать 20 потоков!?

[Barmaglodd]

У меня сейчас в firefox'е 24 потока. И я же не говорю, что это универсальное решение.

[lit-uriy]

>>Интересно, никогда не наблюдал такого. Кинь ссылку на топик.
Речь идёт об устройствах типа USB<->RS-485, кода пользователь выдёргивает на горячую такой переходник, то программисту хотелось бы иметь возможность отследить эту ситуацию

[pastor]

Покопаюсь как будет время с своих исходниках, вроде такой проблемы у нас не было.  Мы работали с IrDA-tp-COM, USB-to-COM

[pastor]

Заглянул в свои исходники: у нас такое событие обрабатывалось извне библиотеки. В общем есть цикл в отдельном потоке, который проверяет кол-во доступных байт для чтения при помощи метода bytesWaiting. Если этот метод возвращает -1 (ошибка) мы закрываем порт и освобождаем ресурсы. Метод bytesWaiting асинхронный, реализованный при помощи WaitCommEvent и WaitForSingleObject

[lit-uriy]

Потому что если открыть порт и выдернуть его - то из этой ветки устройство не исчезнет! На crossplatform.ru уже обсуждали.

Интересно, никогда не наблюдал такого. Кинь ссылку на топик.

начало тут

Если этот метод возвращает -1 (ошибка) мы закрываем порт и освобождаем ресурсы.

Моё:

я использую QxtSerialPort в виндовозе, для отлова отключения преобразователя USB-RS232 при открытом порте всегда проверяю кол-во принятых байт. Драйвер FTDI'ного преобразователя всегда отрицательное значение возвращает.

[kuzulis]

я использую QxtSerialPort в виндовозе, для отлова отключения преобразователя USB-RS232 при открытом порте всегда проверяю кол-во принятых байт. Драйвер FTDI'ного преобразователя всегда отрицательное значение возвращает.

А если, к примеру, байты начнут передаваться только через час, два, три (к примеру, так задумано) - то и о исчезновении устройства ты узнаешь тоже через час, два, три?!
А может и вообще не узнаешь.

[lit-uriy]

>>то и о исчезновении устройства ты узнаешь тоже через час, два, три?!
да. Но на практике это и нестрашно.

[kuzulis]

Доброго времени.

Да собственно проблема в следующем. Эта ошибка возникла у нас на рабочем месте разработчика и её можно обойти, раз, другой, изменяя предлагаемые исходники (что очень сильно надоедает). Но что если, она возникнет уже на стороне клиентов, использующих наш софт. Они же в первую очередь обратятся к нам и что мы им скажем? Разведём руками. Пинайте админа!? В лучшем случае, как говорят на востоке - потеряем лицо (не такие уж мы и гордые). А если вопрос возникнет в некий критический момент, да на нас потом всех собак спустят.

Ну так, для себя один раз измените исходники, они ж опен-сурц, в чем проблема?
Как вариант - возьмите очень старые исходники библиотеки на fireforge.net , там по моему, "тупо" читался реестр, может быть, этой проблемы не будет, измените их и добавьте себе.

Поэтому ещё раз прошу рассмотреть использование в библиотеке альтернативных вариантов получения списка портов.

Найдите альтернативное решение сами, предъявите их общественности (ну и мне) и, может быть, их можно будет добавить в основную ветку через дефайны.
Я сам не намерен этим заниматься.