автоматизировать связи changed*() РЕШЕНО

[Гурман]

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

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

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

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

[Kolobok]

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

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

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

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

[GreatSnake]

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

[Гурман]

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

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

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

[GreatSnake]

...поскольку нельзя написать SIGNAL(colorChanged()) если он colorChanged(QColor), подключение просто не выполнится

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

Код

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

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

[GreatSnake]

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

[Гурман]

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

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

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

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

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

[GreatSnake]

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

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

[BRE]

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

Все просто. 

[Гурман]

Копайте QObject::property() и QVariant().

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

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

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

[Igors]

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

Код

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 и обратно... но там хоть запутаться сложно, хотя пропустить что-нибудь, как нефик делать

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

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

[BRE]

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

[Гурман]

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

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

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

[BRE]

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

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

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

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