Russian Qt Forum
Ноябрь 24, 2024, 18:48 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Russian Qt Forum > Forum > Qt > Вопросы новичков > В конструктор родителя передать имя объекта
Страниц: 1 [2] 3   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: В конструктор родителя передать имя объекта  (Прочитано 11537 раз)
alexis031182
Гость
« Ответ #15 : Апрель 15, 2012, 22:51 »
Alex_C, Igors Вам дал очень дельный совет не наследовать CalcWindow (и др. подобные классы окон) от AbstractLogWindow. Это действительно в будущем, с увеличением размера приложения может привести (и наверняка приведёт) к необходимости добавления в код множества т.н. костылей. Разъедините оба класса, и пусть AbstractLogWindow принимает указатель на окна типа CalcWindow.
Записан
Alex_C
Гость
« Ответ #16 : Апрель 15, 2012, 23:34 »
Чего то я пока ничего не понял - я то как раз хочу размер уменьшить - все в класс - потомок свести. Разве это не правильно??
Записан
alexis031182
Гость
« Ответ #17 : Апрель 16, 2012, 08:09 »
На самом деле через наследование в данном случае Вы не уменьшаете размер. Ну посудите сами: при создании каждого объекта класса CalcWindow будет автоматом создаваться экземпляр класса AbstractLogWindow. То есть, имея, скажем, 30 объектов CalcWindow, Вы получаете по сути 30 объектов AbstractLogWindow. Судя по представленному Вами функционалу AbstractLogWindow в таковом наследовании нет необходимости. Вполне достаточно одного экземпляра AbstractLogWindow на сколь угодно большое количество CalcWindow.
Записан
Alex_C
Гость
« Ответ #18 : Апрель 16, 2012, 09:02 »
Я понял о чем Вы говорите. Просто тот функционал, что я привел - для примера. В реальной программе все существенно сложнее получается, чем просто записывать данные в ini-файл. Конечно,  с Вами согласен - был бы разговор только о записи вида окна - городить огород из наследования - смысла бы не было.
Записан
_OLEGator_
Гость
« Ответ #19 : Апрель 16, 2012, 10:54 »
Зачем хранить лишнее поле с именем.
Я бы сделал виртуальную функцию получения имени объекта, в потомках его переопределял, а в базовом классе при сохранении и загрузке можно в любом месте получить имя, вызвав эту функцию. Нет необходимости хранить это имя.

Можно воспользоваться функциональностью QObject:
Код
C++ (Qt)
QString	objectName () const
void	setObjectName ( const QString & name )
Записан
Alex_C
Гость
« Ответ #20 : Апрель 16, 2012, 11:03 »
Цитата: _OLEGator_ от Апрель 16, 2012,  10:54
Зачем хранить лишнее поле с именем.
Я бы сделал виртуальную функцию получения имени объекта, в потомках его переопределял, а в базовом классе при сохранении и загрузке можно в любом месте получить имя, вызвав эту функцию. Нет необходимости хранить это имя.

А вот это наверное самое правильное решение! Так и сделаю!
Записан
LisandreL
Птица говорун
*****
Offline Offline

Сообщений: 984


Надо улыбаться


Просмотр профиля
« Ответ #21 : Апрель 16, 2012, 11:14 »
Цитата: _OLEGator_ от Апрель 16, 2012,  10:54
Я бы сделал виртуальную функцию получения имени объекта, в потомках его переопределял, а в базовом классе при сохранении и загрузке можно в любом месте получить имя, вызвав эту функцию. Нет необходимости хранить это имя.
В конструкторе/деструкторе родителя нельзя.
А сохранить данные перед выходом может захотеться именно там.
Ну это просто как напоминание.
Записан
Alex_C
Гость
« Ответ #22 : Апрель 16, 2012, 11:27 »
Поторопился. Виртуальную ф-цию в конструкторе не получается использовать - LisandreL прав.  Непонимающий
Какие могут быть еще варианты?
Записан
Alex_C
Гость
« Ответ #23 : Апрель 16, 2012, 11:28 »
Может конечно вообще не заморачиваться - просто название класса ручками прописывать. Но вроде как не по феншую...
Записан
alexis031182
Гость
« Ответ #24 : Апрель 16, 2012, 11:44 »
Судя по тому, что Вы сохраняете для идентификации соответствия настройкам окна имя класса этого окна, то получается, что в Вашей программе будет лишь один объект класса CalcWindow (иначе уникальностью тут не пахнет). А если так, то идентифицировать можно и просто цифрой Улыбающийся
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #25 : Апрель 16, 2012, 12:28 »
Цитата: Alex_C от Апрель 15, 2012,  23:34
Чего то я пока ничего не понял - я то как раз хочу размер уменьшить - все в класс - потомок свести. Разве это не правильно??
Чувствуется кладка дельфийца - давайте раздуем базовый класс "на все случаи жизни" Улыбающийся
Посмотрим а что делает AbstractLogWindow. Разве сохранение/восстановление размеров/позиции окна как-то связано с CalcWindow или др именно Вашими классами окон? Вовсе нет, это можно делать для любого Qt окна/виджета. Отделаться "загрузкой в конструкторе" + "сохранением в деструкторе" все равно не удается. Напр пользователь нажал "Save" - и окна не закрываются но их расклад должен быть сохранен. Также интересно как Вы будете извиваться если потребуется окно что не зависит от QSettings.

Имеет смысл унаследоваться от QSettings и там добавить свои методы - какие-то соглашения по секциям будут так или иначе. Или даже просто сделать сохранение/восстановление глобальной ф-цией (или как говорят синглтоном). Да, придется вызывать его после каждого создания окна, это минус. Но конструктор требующий QSettings (а где его взять?) никак не лучше
Записан
Alex_C
Гость
« Ответ #26 : Апрель 16, 2012, 13:27 »
Цитата: Igors от Апрель 16, 2012,  12:28
Или даже просто сделать сохранение/восстановление глобальной ф-цией (или как говорят синглтоном). Да, придется вызывать его после каждого создания окна, это минус. Но конструктор требующий QSettings (а где его взять?) никак не лучше

Не соглашусь с Вами - потому как в Дельфи у меня так и сделано. Тут же (как мне кажется) можно сделать куда как правильнее. Потому как у меня в программе много отдельных окон, базовый класс для них - самое то. В Дельфи мне приходилось в конструктор каждого окна что - то прописывать (как минимум к глобальным переменным нужно обращаться и т.п.) Тут как раз можно все начальные операции по определению класса сделать "по умолчанию" - по моему это правильно.
Я не настаиваю на своем мнении - хочу услышать почему я не прав.
Записан
Alex_C
Гость
« Ответ #27 : Апрель 16, 2012, 13:40 »
Да кстати о наследии Дельфи - в дельфи унаследовать класс TForm было весьма не простым делом - там ведь ручками прийдется все компонеты на нем расставлять.  Тут же - лайоуты - красота Улыбающийся Как раз поле для классов)))
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #28 : Апрель 16, 2012, 13:56 »
Цитата: Alex_C от Апрель 16, 2012,  13:27
Не соглашусь с Вами - потому как в Дельфи у меня так и сделано. Тут же (как мне кажется) можно сделать куда как правильнее. Потому как у меня в программе много отдельных окон, базовый класс для них - самое то. В Дельфи мне приходилось в конструктор каждого окна что - то прописывать (как минимум к глобальным переменным нужно обращаться и т.п.) Тут как раз можно все начальные операции по определению класса сделать "по умолчанию" - по моему это правильно.
Я не настаиваю на своем мнении - хочу услышать почему я не прав.
Покрутите разные ситуации. Напр у меня есть "Reset Windows" - выстроить окна как они записаны в установках. Как будете делать если у Вас это жестко вбито в конструктор? Или пользователь выходит без сохранения - а у Вас в деструкторе установки окон зачем-то сохраняются. и.т.п. Быстро выясняется что не сам класс окна а какая-то "третья сторона" решает нужно ли загружать/сохранять. Значит надо иметь эти действия в виде ф-ций - и все.

Если "чисто теоретически" то можно объяснить так. Является ли сохранение/загрузка "неотъемлемым" свойством Ваших окон, без которого они не могут жить? Никак не является, очень может быть есть (или будут) окна которым это не нужно. Так чего это свойство вынесено в базовый класс?

Конечно это не является "ужасной ошибкой", "кривой архитектурой" и.т.п. - это молодые любят преувеличивать, а я тоже "из советских времен"  Улыбающийся

Цитата: Alex_C от Апрель 16, 2012,  13:40
Тут же - лайоуты - красота Улыбающийся Как раз поле для классов)))
Заметьте что лайоут никак не входит в базовые свойства
Записан
Alex_C
Гость
« Ответ #29 : Апрель 16, 2012, 17:03 »
Кстати, за всеми этими теоретическими выкладками заметил вот что: у меня положение окна восстанавливается, а его размер - нет. Что не так?

Код:
AbstractLogWindow::AbstractLogWindow(QString winName,
                                     QSettings *s,
                                     bool isModal,
                                     QWidget *parent) :
QWidget(parent)
{
    m_WinSet = s;
    m_WinName = winName;

    uint winState = (isModal? Qt::Dialog : Qt::Window);

    m_WinSet->beginGroup(m_WinName);
    setWindowFlags(Qt::WindowFlags(m_WinSet->value("WondowFlags", winState).toUInt()));
    setGeometry(m_WinSet->value("Geometry", geometry()).toRect());
    m_WinSet->endGroup();
}

AbstractLogWindow::~AbstractLogWindow()
{
    m_WinSet->beginGroup(m_WinName);
    m_WinSet->setValue("Geometry", geometry());
    m_WinSet->setValue("WondowFlags", uint(windowFlags()));
    m_WinSet->endGroup();
}

Смотрю ini-файл - все записывается правильно. Но размеры то почему не восстанавливаются? Т.е. положение - правильное, а размер - нет.
Записан
Страниц: 1 [2] 3   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


Страница сгенерирована за 0.076 секунд. Запросов: 22.