DCTerminal - Моя первая Qt-программа Опции

[DruidCat]

Выделено из темы QtSerialPort, Проблема сборки

Спасибо за совет kuzuils. Помогло.
Я хотел бы выложить свою первую программу на QT. Я её писал и заодно учился QT. Данную программу я написал в IDE Eclipse Kepler + QT 5.1.1. for Windows (MinGW 4..
Это Терминал. Он принимает и отправляет символы по последовательному порту. Так, что если у кого из новичков возникнут вопросы на эту тему, можете заглянуть в исходный код, и будет вам счастье.
Еще хочу сказать про работоспособность, когда я написал простенькую программу на своем МК AVR 328P и сказал ему циклично выводить одну строчку строчку со скоростью 115200 baud. То, когда я подключал сом порт, у меня программа зависала. А если например МК сказать, выслать циклично одну строчку 100 раз. То программа принимает эту строчку 100 раз, но подключал я сом порт до того как начинал посылать 100 раз строчку. Одним словом, у меня знаний не хватает понять, почему так происходит. Так же терминал не понимает кириллические шрифты, я в документации QT нарыл шрифты, типа "Times" и тому подобные, но они не кириллические.
PS: Если кто увидит проблемные места (корявый код) в программе, пожалуйста отпишитесь. Я из тех людей, кто любит учиться и для меня чужой опыт очень ценен.

Прикрепленные файлы

 DCTerminal.zip ( 8,29 килобайт ) Кол-во скачиваний: 265

 

[Iron Bug]

Если кто увидит проблемные места (корявый код) в программе, пожалуйста отпишитесь. Я из тех людей, кто любит учиться и для меня чужой опыт очень ценен.

Ну, лучше этот пост вынести в отдельную тему - ибо он уже не относится к QtSerialPort (это к модераторам).
А так, по коду: очень много конструкций вида

if ( some_string == "some_value" )

лучше сделать через else if

if(...) {...} 
else if(...) {...}
else if(...) {...}
else {...}

чтобы не проверялись все условия для одной строки: если одно совпало, другие уже не совпадут. сравнение строк - очень медленная операция. в данном случае это единичные вызовы, но в более серьёзной программе такие if-ы сожрут процессор.

а что касается открытия порта с зависанием, то вот тут, в ответе, человек очень подробно исследовал данную проблему и пришёл к выводу, что сначала надо открыть порт, а потом уже выставлять все его параметры. это бага (или фича) QSerialPort.

Сообщение отредактировал Iron Bug - 23.10.2013, 18:44

[kuzulis]

Это Терминал.

А терминал из примеров QtSerialPort чем-то не угодил?

это бага (или фича) QSerialPort.

Это фича. Пример из жизни: если хочется покушать - то мы сначала открываем холодильник, а уже потом берем оттуда колбасу..

Хотя может быть в Qt6 это поменяем, т.к. сейчас нет смысла. Да и запарно это...

[Iron Bug]

Это фича. Пример из жизни: если хочется покушать - то мы сначала открываем холодильник, а уже потом берем оттуда колбасу..

Хотя может быть в Qt6 это поменяем, т.к. сейчас нет смысла. Да и запарно это...

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

[Litkevich Yuriy]

Я привык использовать UART по микроконтроллерному.
1) Настраиваю параметры
2) Разрешаю прерывания (читай, "открыл порт")
3) Обрабатываю прерывания.

Поэтому и когда делал обёртку над QxtSerialPort то интерфейс соответствующий предусмотрел. Если же настройки ни какие не ввести, а просто открыть порт, то грузятся предыдущие или те что вбиты в настройках системы. А когда столкнулся с библиотекой Дениса (kuzulis), то мне показалась она вверх ногами.

[DruidCat]

Я привык использовать UART по микроконтроллерному.
1) Настраиваю параметры
2) Разрешаю прерывания (читай, "открыл порт")
3) Обрабатываю прерывания.

Поэтому и когда делал обёртку над QxtSerialPort то интерфейс соответствующий предусмотрел. Если же настройки ни какие не ввести, а просто открыть порт, то грузятся предыдущие или те что вбиты в настройках системы. А когда столкнулся с библиотекой Дениса (kuzulis), то мне показалась она вверх ногами.

Я так же делаю.

Кстати, у меня тоже возникли проблемы в написании данной программы, она у меня принимала гракозябры. Я тоже пытался сначала сконфигурировать порт, а потом его открыть. Но прочтя тему SerialPort на вашем форуме, я нашел ответ. Я после этого заглянул в Example, и там тоже заметил, что сначала нужно открыть, потом сконфигурировать. Спасибо за ответ kuzulis.

На счет if else. В учебниках, которые я читал, везде используется схема, которую посоветовал Iron Bug. Но я не понимал, почему это пишется именно так. Спасибо за совет Iron Bug, я изменю свой стиль написания программ.

[kuzulis]

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

А когда столкнулся с библиотекой Дениса (kuzulis), то мне показалась она вверх ногами.

Я так же делаю.

Да да да. Эта тема уже поднята и бурление начато: https://bugreports.qt-project.org/browse/QTBUG-33774

Там тогда основная проблема в реализации обработок ошибок, т.к. setXX() перед open() еще не означает, что какое-то св-во реально установилось. Оно установится только после open() и пр.

Кроме того, если использовать концепт ООП, то методы setXX() должны возвращать void (по идее), а вся обработка ошибок должна осуществляться серез сигнал error().

Т.е. очень много нюансов... API может быть изменится в Qt 6.0, т.к. раньше нельзя это делать..

[Iron Bug]

там тогда основная проблема в реализации обработок ошибок, т.к. setXX() перед open() еще не означает, что какое-то св-во реально установилось. Оно установится только после open() и пр.

Кроме того, если использовать концепт ООП, то методы setXX() должны возвращать void (по идее), а вся обработка ошибок должна осуществляться серез сигнал error().

про установку: просто юзеру не должно возвращаться что-либо до прогрузки установок, как я это понимаю.
а про код ошибки - это нормальное, технически грамотное решение. я во многих реализациях такое видела и сама так пишу хардовые библиотеки. там фишка в том, что библиотека запоминает поток, который вызвал ошибку, и реально есть целый список, привязанный к потокам. а когда поток обращается за идентификатором ошибки, библиотека по его хэндлу находит соответствующую ошибку. этим решается вопрос работы с многопоточными приложениями, просто и элегантно.
а в Qt много корявостей, факт. и ещё непонятно, собираются (и вообще могут ли) они их решать. ибо там проблемы на уровне архитектуры. слишком они перемудрили с организацией своей шины сообщений и работа с потоками стала весьма кривой и неудобной.

P.S, мы опять тут нафлудили не по теме и надо обратно в тему про библиотеку работы с COM-портами это переносить

Сообщение отредактировал Iron Bug - 30.10.2013, 21:28