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

[asvil]

Поддерживаю b-s-a

[lit-uriy]

>>ты посмотри класс QPrinterInfo. Там нет ничего похожего.
мне он как-то побоку. Я им не пользуюсь

Если либу делать, то делать так, чтобы её можно было максимально эффективно использовать. И наче вообще смысла нет, пусть останется как есть и сейчас всё из неё выковырять можно.

Цикл и можно и нужно записать внутри либы.

И к стати, если с именем порта всё более или мение сносно, то как например дела обстаят со скоростью.
Как заполнить комбобокс и как потом его использовать?

[asvil]

А откуда kuzulis-y знать кто как комбо бокс юзает. Я например вообще модель люблю в него засунуть, так что же мне kuzulis должен qabstractmodel* выдать?

[b-s-a]

И к стати, если с именем порта всё более или мение сносно, то как например дела обстаят со скоростью.
Как заполнить комбобокс и как потом его использовать?

Код

C++ (Qt)
foreach(int speed, info.standardBauds())
   comboBox->addItem(QString::number(speed));

[b-s-a]

Кстати, подсмотрел тут в конкурирующей библиотеке, что можно метод работы со скоростью назвать просто rate:

Код

C++ (Qt)
class SerialPort
{
//...
   enum Rates {
       Rate9600,
       Rate19200,
//...
   };
//...
   bool setRate(int rate);
   int rate() const;
//...
};
 
class SerialPortInfo
{
//...
   QList<int> standardRates() const;
//...
};

[pastor]

А че тролли разве не только своей лаборатории доверяют? Прям так возьмут? Может сначала спросить? или я что-то пропустил...

В Дублине на Миго конференции в кулуарах я пообщался с Thiago Macieira по этому поводу (поддержка COM порта в Qt). Ответили, что в их планы это не входит, но любые контрибуции в этом направлении приветствуются.

[b-s-a]

любые контрибуции в этом направлении приветствуются.

Тем более!!!

[lit-uriy]

>>кто как комбо бокс юзает. Я например вообще модель люблю в него засунуть
>>так что же мне kuzulis должен qabstractmodel* выдать?
Если ты так любишь применительно к COM-порту, то ты тот ещё лисапедист.

[lit-uriy]

Тем более, что не сложно сделать:

Код

C++ (Qt)
foreach(const SerialPortInfo &info, SerialPortInfo::availablePorts())
   comboBox->addItem(info.name());

Код

C++ (Qt)
foreach(int speed, info.standardBauds())
   comboBox->addItem(QString::number(speed));

Ну в принципе убедил, довольно компактно. Пусть так будет.

[kuzulis]

Ну, парни, лады. Раз с API в принципе более менее устаканились, теперь можно создавать новую ветку на гиториусе.
Теперь:
1. Как назовем эту ветвь?
2. Как в "родном" Git GUI под винду теперь создать и залить на сервер новую ветку? Желательно по пунктам (а то я могу запаганить всё что там есть сейчас ).
 

[b-s-a]

kuzulis, добавь меня коммитером, сделаю тебе чистую ветку.
Но прежде чем заливать стоит выложить сюда окончательные версии интерфейсов для финальной ревизии (а то вдруг опять кто-то кого-то не понял, или подзабыл).

[b-s-a]

Теперь предлагаю спуститься с небес чуть ближе к реализации...
Лично мне (точнее, моей конторе) нужна реализация позволяющая строго контролировать время приема/передачи данных. Дискретизация времени в Windows полностью не устраивает (нужна точность 5 мс, а в Windows ~18 мс), поэтому в моей реализации в waitForReadyRead использовано ожидание посредством комбинации стандартного (waitForSingleObject) и точного (через PerfomanceCounters) методов, а waitForBytesWritten я вообще реализовал через жесткое ожидание (количество байт * количество бит в посылке (6 ... 12) / скорость). Это все необходимо, так как нужно отправить 1 байт с четностью Mark, затем сколько-то с четностью Space (между всеми байтами не более 5 мс), дождаться полного ухода данных, а затем ждать ответ с четностью Space не более 20 мс (между соседними байтами не более 5 мс).
Дальше, я против создания каких-либо служебных потоков. Лучше просто повесить стандартные таймеры (startTimer/killTimer) для проверки состояния линий и отправки/приема данных. Периодичность можно захардкодить (200 мс, например) или дать пользователю возможность настройки (setLineCheckLatency, например). Более того, события отправки данных таймер даже хардкодить не надо - достаточно просто обновлять время срабатывания после выполнения writeData.

[lit-uriy]

>>2. Как в "родном" Git GUI под винду теперь создать и залить на сервер новую ветку?
Можно в Git GUI, а можно и в Git Tk, который историю показывает.

Перейти в Git Tk можно из Git GUI, Меню "Хранилище (репозиторий)" -> "Показать историю всех ветвей"

*Git GUI
Меню "Ветвь"->"Сздать"
вводишь название
указываешь начальную версию (ветвь от которой ветвится нужно)
Если хочешь сразу на неё перейти ставишь галку "после создания сделать текущей"

* в Git Tk (удобнее когда надо задним числом её сделать)
тычешь состояние, от которого хочешь ветвится
правой кнопкой вызываешь контекстное меню, в нём пункт "Создать ветвь" в открывшееся окно вводишь имя.
Всё, ветвь создана, если хочешь на неё перейти, тычешь правой кнопкой по имени ветви (зелёненькая подпись), а не по состоянию. В контекстном меню выбираешь "Перейти на эту ветвь" (Если выскакивает окно о типе перехода, то можно выбрать "Жёсткий" вариант, но не сохранённые изменения в рабочем каталоге будут потеряны)

[lit-uriy]

>>нужна реализация позволяющая строго контролировать время приема/передачи данных.
Если речь идёт о приёме по таймаутам, то это не реально.
Т.к. система (в драйвере порта) не регистрирует время, в которое происходит прерывание от приёмника UARTа.

[lit-uriy]

>>Дальше, я против создания каких-либо служебных потоков. Лучше просто повесить стандартные
>>таймеры (startTimer/killTimer) для проверки состояния линий и отправки/приема данных.
А зачем потоки? Есть же события в системе. Кажется называется overlaped