Нет. Это нужно для этого, пример:

1. Допустим либа 0.2.0
1.0. Запустили SerialDeviceWatcher.
1.1. Открыли порт методом open и работаем с ним.
1.2. Выдернули физически сам usb/serial конвертер из USB порта компутера.

Результат: SerialDeviceWatcher не зафиксирует событие о том что порт извлечен, т.к. записи в реестре для этого порта по путям (в 0.2.0.) останутся неизменными.

2. Допустим либа Git
2.0. Запустили SerialDeviceWatcher.
2.1. Открыли порт методом open и работаем с ним.
2.2. Выдернули физически сам usb/serial конвертер из USB порта компутера.

Результат: SerialDeviceWatcher зафиксирует момент извлечения устройства, т.к. записи по путям (в Git) автоматически удалятся!!!


Ну, за все нужно платить. Это закон природы: в чемто выигрываем, а в чем то проигрываем.
На то и имеются исходники чтобы добавлять туда поддержку новых девайсов.
Тем более, их не стопицот тыщ, а с несколько десятков.
Тем более, если вы соберете библиотеку как *.dll/*.so то вам не придется перекомпилировать все приложение, а только библиотеку!


ну так и не будет значит и либа детектить эти порты!

Сообщение отредактировал kuzulis - 6.8.2010, 15:00

Из документации MOXA NPORT
"Обратите внимание, что виртуальные порты MOXA НЕ отображаются в списке последовательных
портов в «Диспетчере Устройств» Windows. Это нормальное поведение для виртуальных COM-
портов: они не будут отображены в списке устройств Windows, но, при корректной настройке, будут
доступны для работы любому приложению." ???

Ну, имхо, тогда никак не получится.

Сегодня добавил новый класс SerialDeviceEnumerator который в будущем должен заменить два класса: SerialDeviceWatcher+SerialDeviceInfo (т.е. я их планирую удалить вообще). В новом классе по идее должны работать любые девайсы.. Прошу потестить.

не согласен с именованием и объединением.
Название SerialDeviceEnumerator удачно и привычно. Он может заменить SerialDeviceInfo
А вот SerialDeviceWatcher всё-таки должен быть автономным (пусть внутри он и обращается к перечислителю портов, его можно сделать дружественным для перечислителя).

Я тоже сомневался. Просто я "существенно" изменил алгоритм и реализацию SerialDeviceInfo и поэтому "пришлось" их объединить.



Поподробнее пжлста.

Сообщение отредактировал kuzulis - 12.8.2010, 20:56

Я не знаю как он у тебя работает/должен_применятся.
Я думаю, что по аналогии с QFileSystemWatcher. Т.е. подключился к его сигналу, если сигнал сработает, то приложение как-то на него реагирует.

При статической сборке с приложением, если не нужен этот класс, можно его подключать - удобно

Ну так исходники SerialDeviceEnumerator же есть !

Фишка в том, что в реализации SerialDeviceEnumerator теперь всЁ упрощего и унифицировано, т.е.
при изменении (втыкании/вытыкании) порта теперь автоматом перечисляются все оставшиеся устройства в системе и обновляется инфа о них в мапе

QMap<QString, SerialInfo>

т.е. для получения инфы об нужном у-ве мы в данном случае просто берем уже готовую инфу для интересующего у-ва из мапы и нет необходимости для ее получения вызывать OS API. т.е. если у-во в наличии в мапе - то оно, естественно, в наличии и в ОС!!!

Получается еще удобнее чем было раньше.
Ну подумаешь, что теперь SerialDeviceEnumerator включает в себя Watcher + Info ... Ну и что с того?

Если делать как ты говоришь, то все-равно придется в Watcher включать код от Info и т.п. так какая разница?

2 kuzulis,
если можно есть пара вопросов:
1. не получается обработать ошибку установки параметров скорости для порта, для порта на плате задаю скорость которую он не поддерживает 230400 бод, естественно возникает ошибка установки
Windows: NativeSerialEnginePrivate::nativeSetBaudRate(AbstractSerial::BaudRate baudRate)
-> function: ::SetCommConfig(this->m_descriptor, &this->cc, sizeof(COMMCONFIG)) returned: 0. Error
для обработки ошибки делаю так (как у вас в доке)
MyDevice = new AbstractSerial();
MyDevice->enableEmitStatus(true);
connect(MyDevice, SIGNAL(signalStatus(сonst QString,QDateTime)), this, SLOT(DisplayError(QString,QDateTime)));
и
void MyThread::DisplayError(QString& message, QDateTime cur_time){
qDebug() << "State: " << message << ", in time: " << cur_time.time().toString(); }
но в слот DisplayError я не попадаю, скорее всего, что это мой косяк, но пока не понимаю где...

2. можно ли сформировать список скоростей передачи поддерживаемых портом, аналогичный Диспетчер Устройств/Последовательный порт/Свойства/Параметры/Скорость передачи, что бы дать выбор при задании параметров порта, а не отлавливать ошибки при задании неверной конфигурации?

2 good835

1.

Т.е. вообще никакие ошибки не отлавливаются или только при установке скорости?

2.

Попробуйте использовать Win32 API ф-ю: GetCommProperties или что-нибудь подобное. Но не факт что оно получится. Иного решения я не знаю.
Но это не кроссплатформенное решение и поэтому я не буду это реализовывать (по крайней мере пока)