Я очень вежлив вроде как ...


так далее я должен как я и говорил создавать свой класс от родителя QlineEdit и в нем расприватив KeyPress с ним работать ... хорошо то как тогда мой клас сунуть и расместить в дизайнере ?

я не понимаю почему у меня баня не через дорогу отраздивалки а в другом городе ? причем тут билдя VC все так же просто хоть и пишется руками но в дизайнере все можно раставить


в общем походу я сделал выводы по Qt и они т еже что и о QT ... просто столько проблем на ровном месте  в самой банальности .. я даже не знаюза чем еще может существовать Line Edit если не для обработки ввод...

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

за ранее приношу извенения за то что пришели нагадил ... но мои ожидания были совеншенно другими ...

И еще советую почитать Крылова "Мартышка и очки". Крайне полезная басня.

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

ЕЩЕ РАЗ БОЛЬШОЕ СПАСИБО, за терпение и возюкание со мной ...
и так впринципе ты (надеюсь можно ) подтвердил то о чем я говорил ноне мог объяснить
либо я варю обработчик событий :

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

Седят в protected
ну или вытасукивать их через создание потомка класа и выуживанием в паблик эти эвенты ...

в общем то с чего начинался весьсрач просто толи я не мог норм задать вопрос толи это считается в Qt идельным решением и нормой ... как само сабой разумеющееся ...

в общем итог либо ты пишшеь много кода , либо отправляешь на свалку дизайнер и опять же таки пишешь много кода ...
и этоглавнейшая проблема Qt вообще даже страшнее отсутсвия сборки в один файл ... я все таки планирую по тихо продолжать смотрть в этомнаправлении но увы констатирую факт Qt на текущий момент является отсталой технологией не позволяющей :
1- делать быструю разработку
2- имеющую непонтнуб логику "оно есть - но чтобы взять надо выполнить квест походу которого вы чего то лишитесь"
3- отсутсвие встроенных средств сборки всего в 1 exe файл как я выяснил и в лине та же ботва , нужнотащить все либы за собой

про плюсы молчу ибо эти минусы просто сводят их на нет ...

готов к швырянию в меня какашками ...
Басня хороша .. но не к месту ... тут скорее всего стоит вспомнить мультик "почему у льва большая грива"

Отвечаю на ваш вопрос,  я оч много лет работаю на фрилансе , как соло так и в рабочих группах последние года я немного переквалифицировался в Промышленногопрограмиста  но в свое время писал корпоративный софт
приведу тебе просто пример , софтина огромная 20 разных рабочих модулей (бухи, склад и прочее) я писал часть взаимодействия с SQL  тоесть прокладку работы с базой данных которая отслеживала  связи перекрестные ссылки ипрочее в общем вся движка ... я сделал и отладил это за 2 недели ... чувак другой писал отчеты конструктор и и прочее он это сделал за месяц ,  при этом каждый для себя накидывал интерфейс ... нетратят на это время ... а уже потом отдельный человек согласовывая с заказчиком разрабатывал то что тот хотел видеть розовые кнопочки и красивые темы ... и на это ушел год поделок и переделок и да это был VC а тамнет проблем с обработкой банальности

так далее мне нет смысла тратить время на прописывания фигни ...

ну и возникает вопрос на кой ЛАД тогда нужен редактор если его использование не считатеся хорошим тоном и вообщ ене поддерживается  адекватно ?
почему фактически основное седит в привате ?

где логика ...
вы ошиблись я много програмирую в лине , правда все что я делаю обычно работает в консоли или демонами и оконного интерфейса там нет ...
подход с слотами мне знаком а про события я вообще молчу ... но чет я не помню чтобы хотьраз мне приходилось основопологающее событие из какой либо либы выуживать через отладчик ... (корявая аналогия с private) хотя конечно такое делал ... но скорее для развлекухи...
Могу ли я процетировать тебе то как дали ответ на такую рекомендацию на одном из англоязычных форумов ..
why don`t I then write my own libraries to bury Qt ??

в общем я согласен ...  примерно если перевести то "почему бы мне не сделать свои либы чтобы похоронить Qt"

имеется в виду не использовать ...

Я еще раз извеняюсь если груб но подумайте самикак стыдно задаватиь такой вопрос и тепретька ктебятыкают в лоток с наполнителем ...
Отдельное спасибо Пантер`у единсвенный кто пытался помочь ...

p.s.и да сейчас 90 % времени уходит именно на создание интерфейса ... и увы если вы комерческий разработчик а не любитель вы это должны знать так как софт это  вопервыхтоварлецом а уж во вторых функционал

p.p.s Igors, а можнопару примеров софтины где в принципе не нужен интерфейс и клепание форм а 99% уходит именно на разработку кода процесса исполнения (игры не считаем ибо QT для этого вообще не торт) какойто спец сфот математика ? статистика ? сколько вы такого софта написали ?

Кстати, после перехода с билдера на Qt я первые пару лет вообще не пользовался дизайнером, создавал все в коде, чтобы привить себе понимание того, как все это работает на самом дела. Потому что с Билдером я не знал ни что такое события, ни откуда они берутся, ни что такое event loop - я умел только мышкой натыркать контролов, стырить код из сборников FAQ, коих было немеряно и как-то это все запустить. Стоит ли говорить, что качество софта, а самое главное, качество моих знаний было чуть выше чем никакое. Это как php - ты можешь быстро клепать формы, но это не делает тебя программистом. Собственно, у ТС сейчас проблема - он пытается выбраться во взрослый мир из своего детского сада, где ему Билдер даже попу подтирает.

Нет ни одного правила общения в форумах, который бы этот "программист" не нарушил. К доктору. Пантер, не трать на него своего времени, вдруг он здесь останется, и опять придется здесь видеть его "срач".

Вам уже 10й раз пишут - вам не нужны эвенты, вам нужны сигналы. Нельзя сделать connect на эвент. Как нельзя сделать на переменную или макрос. Это разные сущности.
mousePressEvent(), mouseReleaseEvent() - это обработчик эвента (эвент - это объект, посылаемый другому объекту). Он низкоуровневый и туда надо лезть только если хнаешь что делаешь. Эти низкоуровневые обработчик испукают высокоуровные сигналы
clicked(), pressed(), released() к которым можно (и нужно) делать connect().
Сигнал-слоты - это механизм коллбеков, где слот - это ваш коллбек, а сигнал - специальная функция, которая вызывает все присоединенные коллбеки. Они даже называются по-другому, я не зря выделил жирным. Глагол в прошедшем времени - это имя сигнала к которому можно делать коннект. Всё иное - рандомная функция которую кто-то где-то зовет и к которой нельзя делать коннект.
Пока вы не поймете разницу между сигналами и обработчиками эвентов, вы далеко не уедете. Это разные сущности которые хоть и связаны, но выполняют разные задачи.

Логика в том что эвент посылается объекту. Например QMouseEvent посылается виджету под мышкой, а QKeyEvent - объекту в фокусе. Ключевое - объект всегда известен.
Сигнал же посылается "в никуда" - когда кнопка эмитит сигнал pressed() она не знает кто к ней приконнекчен, сколько их и приконнекчен ли кто-то. Она просто посылает сигнал. Если есть подписчики - хорошо, нет подписчиков - тоже хорошо. Таким образом обеспечивается разделение интерфейсов объектов - у одного объекта есть сигналы, у другого - слоты и они друг о друге вообще ничего не знают.
Можно ли сделать это на эвентах? Можно - объект мог бы посылать сам себе эвент QClicked а мы бы его ловили через эвент фильтр. Но это неудобно, потому что вместо функции с нулем-двумя параметрами пришлось бы делать миллиард мелких структур-событий.
Посмотрите на количество сигналов у некоторых классов и прикиньте если бы на каждый метод была бы своя структура.