Com порт,поток и другое

connect(&thisPort, &QSerialPort::readyRead,this, &TPort::ReadInPort);

Рекомендуємо хостинг TIMEWEB

Stabiles Hosting des sozialen Netzwerks EVILEG. Wir empfehlen VDS-Hosting für Django-Projekte.

День добрый.

1) По первому вопросу

С таким функционалом я особо не работал, но встречался с подобным при работе с сетью, поэтому выскажу свои мысли.

Нужно сразу буферизировать данные. Если они не большие, то можно использовать какой-нибудь QList, и использовать компаратор по дате , например, или использовать QVector, но так, чтобы забирать и складывать данные по принципу первый вошёл - первый вышел . По приёму данных записывать их в этот буффер. По записи в буффер вызывать сигнал о том, что была сделана запись. По которому уже забирать данные из буффера. Если учесть, что com-порт у вас в отдельном потоке, то буффер стоит сделать в главном потоке. Информацию передавать по сигнал/слотовому соединению. Остаётся тогда проблема в том, как сообщить программе, что в буффере что-то есть. Думаю, что также можно кидать сигнал из буффера, что данные были приняты. А дальше уже реализовывать разбор данных из буффера с удалением обработанных данных.

Можно также для буфферизации использовать базу данных, например, SQLite, если объёмы данных достаточно большие, а поступают они не очень часто.

Ещё я посмотрел бы в сторону QBuffer и производных классов, думаю, что должно подойти, но придётся наследоваться от него и переопределять некоторые методы. К сожалению, с ним почти не работал.

2) По второму вопросу

Если я понял правильно, то обработку данных и запрос к БД вы делаете в потоке COM-порта. В этом и проблема с окном. Но если сделать буффер в main потоке, то есть в потоке GUI, и сделать там же обработку данных, то станет уже несколько проще, поскольку можно будет не только открывать окно, но и добавлять информацию в открытое окно, также через сигналы и слоты соответственно. То есть, если виджет ещё не открыт, то открываем его, если уже открыт, то обновляем информацию в данном виджете. Виджет тогда нужно объявить в заголовочном файле и чтобы один его экземпляр существовал и к нему были подключены соответствующие сигнал/слотовые соединения.

Пока такие мысли у меня, естественно в процессе workflow что-то измените, а что-то усложните в данной концепции. Но обработку данных, считаю стоит убрать из потока, где крутится класс COM-порта. Пускай он только принимает данные и отправляет их в основной поток программы. А там уже будет буфферизация и остальная обработка.

1) Задержку можно реализовать с помощью того же самого таймера, в самом классе, который отвечает за считывание данных. И игнорировать все входящие данные в течение определённого периода. Либо сделать временное хранилище с тем же самым QMap, в котором в качестве ключа будет храниться уникальный идентификатор штрихкода с временем жизни. То есть в качестве ключа будет Id штрихкода, а в качестве значения - время жизни. При считывании данных проверять наличие id в QMap, если он есть, то смотреть время жизни. Если не истекло, значит игнорировать обработку, если истекло, значит можно считать повторно. Время жизни установить допустим 15 секунд для считывания.

2) Вообще, если виджет подразумевается как окно, то может открыться, как таковой проблемы в этом нет. Что касается того, что помешает ли работе gui, то может быть, но если учесть уточнение по работе программы из первого вопроса, то я уже не вижу большой необходимости в переносе буфера в main, можно и там оставить.

1. Таймер тут к сожалению не подойдет, т.к. не известно сколько времени нужно будет,а брать слишком малое черевато. QMap тоже не подойдет, посетитель может зайти и позже, но если он будет в контейнере, может сработать не верно,я все таки думаю сделать, через переменную.
2. Вот тут разобрался, вроде все заработало
Спасибо большое вам за вашу помощь.

1. Тогда сначала нужно описать все возможные дозволенные варианты поведения посетителя и потом уже отталкиваться от них. Поскольку начинается такая ситуация:
-Давайте сделаем задержку.
-А если посетитель уйдет?
-А если посетитель вернётся?
-т.д.
Нужно описать все эти если, то есть написать User Story фактически на этот кейс. И уже на основе него думать над возможным функционалом и решением.