Russian Qt Forum

есть многостраничный диалог настроек с десятками контролов, надо собрать с них всех сигналы changed*(), чтобы знать, когда надо копировать настройки при закрытии диалога, когда не надо (можно, конечно, по Ок переписывать всегда, а по Cancel всегда хренить, но как-то это не очень нравится, тем более, что надо по Cancel выдать предупреждение, если настройки были изменены)

а эти changed*() Тролли умудрились сделать очень разнообразными, где-то параметр int, где-то другой...

и теперь грустно, что придется руками писать, кроме копирования настроек, еще и различные слоты, к которым changed*() должны быть присоединены, и в конструкторе диалога настроек еще все это соединять, и не забыть, и не пропустить ничего, а контролов... десятки...

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

Воспользуйся QSignalMapper


Как вариант, если лень самому все делать, храни настройки в бд. По Ок делай commit, по Cancel rollback.

Никто вам не мешает навешивать один слот changed() без аргументов на все "changed*()" сигналы.

можно конечно и один слот changed() сделать, но это ничего не меняет по существу - все контролы все равно нужно будет по отдельности подключать, поскольку нельзя написать SIGNAL(colorChanged()) если он colorChanged(QColor), подключение просто не выполнится, и регулярный механизм для гомогенного подключения сигналов QtColorPicker::colorChanged(QColor) и QComboBox::currentIndexChanged(int) тут не просматривается

а QSignalMapper наверно было бы то, что надо, но в другой реализации - а так все равно надо руками его подключать ко всем контролам, нет разницы, также точно можно и без QSignalMapper просто один слот в классе диалога создать

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

Вы меня не поняли. Я говорил про другое.
Зачем менять содержимое сигнала? Нужно правильно описать сигнал и повесить на него один общий слот:

C++ (Qt)
connect( colorPicker, SIGNAL( colorChanged( const QColor& ) ), this, SLOT( changed() ) );
connect( comboBox, SIGNAL( currentIndexChanged( int ), this, SLOT( changed() ) );
 

Другое дело, что юзер может изменить сожержимое контрола, а потом вернуть его обратно и состояние изменения должно по-хорошему сброситься для него. Но это уже вам решать.

На самом деле, можно сделать намного красивее и вообще не завязываться на "changed*()".
Во время создания диалога в свойствах контрола сохраните его значение. В accept() пробежитесь по всем контролам и сравните текущее с сохраненным. Всё просто)

я то как раз понял, поскольку так и предполагал сделать, но вы меня не поняли... :)

я могу написать несколько десятков строк с connect, но стараюсь от этого избавиться, поскольку при добавлении или удалении контролов надо добавлять или удалять соответствующие им connect-ы, и вообще в нескольких десятках контролов нетрудно запутаться, что-то потерять и т.д. - я говорю о решении, которое бы подключало ВСЕ контролы диалога, независимо от их числа и типа


с точки зрения количества подключений и вероятности ошибки это практически тоже самое, что подключить все контролы к одному слоту построчно, поскольку функции получения значения контрола у всех типов контролов разные, и возвращают разные типы данных, значит их нельзя просто пробежать в цикле foreach( control, controlList )

Мде, т.е. вам нужна волшебная палочка)
На самом деле тролли подумали о ней. Копайте QObject::property() и QVariant().

В Qt есть возможность:
* получить список всех дочерних виджетов на главном;
* добавить property для каждого объекта, в том числе дочернего виджета;
* получить имя класса для объекта;
* для каждого класса виджета имя сигнала об изменении - известно.

Все просто.  :)

вот-вот-вот... истина где-то рядом... (С) Малдер

если бы property() понимал сложный запрос с wildcard типа property( "*Changed(*" - можно было бы просто запросить каждый контрол... хотя наверно можно через metaObject получить все сигналы, и QRegExp-ом отобрать нужные

кто-нибудь делал? все получается?

Я накручивал примерно так (псевдокод)

C++ (Qt)
struct DataRec {
 enum dataType { 
  data_int = 1,
  data_float = 2,
  ...
 };
 
 enum ctlType { 
  ctl_LineEdit = 1,
  ctl_Combo = 2,
  ...
 };
 
 dataType mDataType;
 ctlType mCtlType;
 union {
  void * voidPtr;
  int *   intPtr;
  float * floatPtr;
  ...
 };
};
 
QHash <QWidget *, DataRec> theControlList;
 

Ну понятно DataRec имеет много методов для передачи данных из UI в пользовательские структуры и наоборот. Задумка автоматизировать операции пробегаясь по QHash (знаем источник и приемник). Впрочем для немодальных окон changed() все равно приходится отслеживать/связывать, можно лишь упростить дальнейшую обработку.

все равно в таблицу надо руками добавлять, и не попутать dataType и ctrlType, хочется чисто динамически, поскольку диалог настроек полностью рисуется в Дизайнере

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

просто контролов в настройках очень много

че-то не вижу я, как получить список слотов КуОбъекта, наверняка есть, но не туда смотрю

Посмотри эту статью: http://doc.trolltech.com/qq/qq11-mandatoryfields.html
Думаю идея появится.

ну влоб их способ не годится - там описан метод add() который добавляет контролы, а у меня они в дизайнере рисуются

а вот widget->inherits( <имя класса> ) и подключение сигнала изменения этого класса - похоже на то, что надо, можно пробежать по всем виджетам настроек, и аналогичным образом их подключить

надо только не забывать добавлять соответствующую проверку имени класса, если будет использоваться контрол, наследующий какой-нибудь класс, который еще не включен в проверки

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

Добавить в конец одну секцию else с Q_ASSERT_X вроде сложно забыть.  :)

А если при закрытии диалога в методе closeEvetn пробегаться по всей форме и сохранять все в реестр, при старте в конструкторе восстанавливать. Или я не понял суть вопроса?

именно

собственно решение уже фактически найдено, надо только реализовать его, руки дойдут сделаю

а реестр идет лесом, у Qt надо пользоваться QSettings

BTW: кто знает, можно ли корректно (без хаков с #define) на винде QSettings перенастроить так, чтобы не в реестр писало, а в INI файл, чтобы настройки сохранялись в каталоге приложения (чтобы оно работало без инсталляции, с флешки)?

QSettings::QSettings ( const QString & fileName, Format format, QObject * parent = 0 )

Ну вроде в документации написано:

Пример: есть список нескольких экземпляров объектов одного типа. Данные показываются/редактируются в немодальном окне. Выбрали из списка один экземпляр - его данные в окне. Выбрали другой - его. Что будете делать если завязались на QSettings?

пардон, и правда написано... :)

а задача решена! работает!  ;D

кусочек конструктора диалога настроек

причем последний виджет не из комплекта Qt, добавлен отдельно

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

кстати, совет добавить туда Q_ASSERT_X не годится - findChildren оббегает все виджеты, причем рекурсивно, а кроме активных селекторов на диалоге находятся еще пассивные метки и полуактивные программно изменяемые нередактируемые строки (например, сэмпл текста с разными подсветками) - поэтому в if-ах должны быть только те классы, которые точно будут генерить сигнал изменения


а давайте без оффтопика...

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

создайте отдельную ветку, если интересно дальше это обсуждать

Не годиться в том виде, что сделал ты.  :)
Например, можно было каждому объекту (виджету), который должен участвовать в проверке, добавить свойство. И соответственно проверять вначале, если это свойство true, то смотреть, что это за класс. Вот там бы этот assert пригодился.

ой мама... это же что получилось бы? :o свойство добавлять руками?? тогда в чем глубокий смысл всего этого??? получилось бы еще хуже - добавился виджет, и к нему надо еще дописать хренов код для добавления ему свойства... :-[

а если не руками, то... как определять автоматом какому виджету надо его добавить????  ;D

а сейчас я уже переделал на цикл по массивам, и при добавлении виджета единственное что надо сделать - если на диалоге еще не было такого класса виджетов, то его имя класса надо вписать в конец массива char*, а в конец другого массива char* вписать имя сигнала об изменении, И ВСЕ!

Когда тебе рекомендовали тот или иной вариант, никто не знал, что же тебе на самом деле нужно.
Подошел простой вариант - хорошо, но... Возможно понадобиться на страницы добавить виждеты, которые не должны влиять на флаг изменения и соответственно не должны сохраняться. Например, это checkbox "Точная настройка", которая показывает большее количество параметров или скрывает их. Этот виджет нужен только для удобства пользователя и никак не влияет на настройки системы. При таких условиях и пригодились бы property, которые можно было задавать в designer'е.

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

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

Это знал только ты.  :)

А вот жестко задавать такое поведение в коде, как раз и есть зло, от которого и нужно уходить.

не согласен

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

в диалоге настроек приложения таких строк для добавления свойств если будет, то 2-3-5, а виджетов, которые генерят нужные сигналы изменений - десятки, возможно даже больше сотни

Это решает лишь частную задачу (отловить "были ли какие-то изменения") да и то плохо, до первого undo, как уже сказали выше. Стандартный путь лучше

C++ (Qt)
MySetting temp = theGlobalSettings;    // делаем копию
if (SettingsDialog(&temp).exec())  {      // пользователь редактирует и жмет Ок
 if (!theGlobalSettings.Equal(temp))  {   // можно и оператор !=
  theGlobalSettings = temp;                 // принимаем новые установки
  theGlobalSettings.Save();                 // сохраняем на диск
 }  
}
 

Непонятно что же Вы тогда "автоматизируете" если все равно пишете все сигналы/слоты вручную?  :)

Ну так можно добавить свойства (NoAutoConnect) для 2-3-5 виджетов и проверять его, а все остальные виджеты (без этого установленного свойства) коннектить автоматически.

А хардкорить в коде поведение для 2-3-5 избранных виджетов путь к получению кучи сюрпризов во время дальнейшего сопровождения кода. И здесь уже не важно кто с этим согласен, а кто нет.  :)

Igors

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


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

и если добавляется контрол, тип которого еще не поддерживается, как написал выше, добавляю только две строчных константы в массивы

насчет undo замечание верное, но это пока терпимо, может потом переделаю иначе, это не трудно

BRE

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


а сейчас там разумеется просто changed = true;

Мы про одно и тоже говорим?
Я про свойства QMetaObject.
Посмотри на:
QVariant QObject::property ( const char * name ) const
bool QObject::setProperty ( const char * name, const QVariant & value )

Также эти свойства можно задавать непосредственно из дизайнера.

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

хотя с точки зрения банальной логики мало разницы между тем, присоединен ли лишний виджет, но его сигнал игнорируется, либо не присоединен - разница только в количестве проходящих сигналов, но если таких виджетов 2-3-5, то их сигналы несущественны

Наоборот, будут в разы меньше, ведь Вам надо сравнить просто данные - UI уже отработало. Это сравнение длинно но несложно, оно сплошь и рядом встречается, операции == и != интуитивны. А вот зарядить данные в UI и принять их оттуда - прекрасно автоматизируется и ходов здесь не один. Более того, connect легко поставить на автомат/пулемет (а не выписывать каждый раз). Ну а про "научить копироваться" неудобно и вспоминать - если нет "С" структур - то это уже готово  :)

Не стоит гнаться за слишком умной системой которая все делает автоматом/интерактивно. Да, кое-что придется писать руками - и для каждого члена данных. Вопрос в том как сделать это 1 раз, а не долбить как дятел