Здравствуйте, гость ( Вход | Регистрация )
SABROG | Дата 4.2.2009, 11:39 |
Мое дело предупредить, а уж кто как захочет ваше дело. Я пытаюсь мыслить глобально. | |
Tonal | Дата 4.2.2009, 9:49 |
QObject - не обязательно виджет. QTimer например. Читаем, что же изначально хотел автор: ...Так вот хочется максимально упростить написание клиентской части и так как там не предусматривается никакой логики разработку основной части клиента хочется перенести в qt designer... QTimer-а в дизайнере нет. Он создаётся в коде. Если есть код, то почему в нём же и не связать его со всеми нужными слотами? |
|
SABROG | Дата 4.2.2009, 9:18 |
QObject - не обязательно виджет. QTimer например. | |
Tonal | Дата 4.2.2009, 9:04 |
Что-то помоему как-то всё через чур сложно. Может по другому прощее будет? Например: 1. В дизайнере создаётся интерфейс (UI форма). 2. Для виджетов, сигналы которых нужно транслировать добавляется динамическое свойство с именами сигналов. 3. "Лёгкий клиент" грузит ui-шку (QUiLoader), пробегается по всем её виджетикам, и для тех у кого есть соответственное динамическое свойство создаёт нужные конекты в которых вся нужная инфа и отфудболивается на сервак. И не нужно никаких хаков Qt. Кроме того, покуда не изменились имена можно безболезненно менять интерфейс. Так же клиент полностью не зависит от UI, т.е. его вообще не нужно перекомпилять при добавлении новой формочки. |
|
SABROG | Дата 3.2.2009, 18:02 |
ну теперь, по идее, должно все работать. | |
fantom | Дата 3.2.2009, 17:01 |
SABROG ты сам запутался и меня запутал. короче никаких using и наследований использывать не надо. Вот так все работает.
|
|
SABROG | Дата 2.2.2009, 20:39 |
fantom Ну чтобы не вылезло можешь в каждом своем наследнике от QObject писать
Этим мы просто говорим чтобы поле d_ptr стало public. Тогда никаких проблем быть не должно. Конечно понимаю что все это изврат и костыли, но если очень надо то больше вариантов я не знаю. Я говорю об объектах, реализация которых скрыта в файлах библиотек. Есть только хедер и .lib/.a файл. И о проектах в исходники которых тебе не захочется лезть. Например комплексные, встраиваемые виджеты с кучей дочерних элементов. Придется много кода переписать, чтобы их всех "отнаследовать". Может это можно как-то по-нормальному сделать? Если все коннекты мы сами делаем, то почему-бы не "запитать" пришедший сигнал на наш слот-ретранслятор, например slt_btn_clicked(). Далее emitим' сигнал дальше на обработчик:
Соотв. все зеркальные сигналы законнектить на один слот.в нас. |
|
fantom | Дата 2.2.2009, 19:18 |
Ну чтобы не вылезло можешь в каждом своем наследнике от QObject писать
Этим мы просто говорим чтобы поле d_ptr стало public. Тогда никаких проблем быть не должно. Конечно понимаю что все это изврат и костыли, но если очень надо то больше вариантов я не знаю. |
|
SABROG | Дата 2.2.2009, 18:45 |
fantom Этот код работает только в пределах одного объекта, который выпускает и ловит сигнал. Ты прав. Я об этом не подумал. Но это лечится. Достаточно ввести новый класс
И теперь уже все объекты от которых надо идентифицировать сигналы унаследовать уже от него, а не от QObject Проверил исправленный код у меня вроде работает. Чувствую, что где-нибудь в другом месте косяк потом с этим вылезет. Например с чужими плагинами или библиотеками. |
|
fantom | Дата 2.2.2009, 17:34 |
Этот код работает только в пределах одного объекта, который выпускает и ловит сигнал. Ты прав. Я об этом не подумал. Но это лечится. Достаточно ввести новый класс
И теперь уже все объекты от которых надо идентифицировать сигналы унаследовать уже от него, а не от QObject Проверил исправленный код у меня вроде работает. |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 29.3.2024, 13:03 |