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

[hackoff]

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

[Гурман]

Или я не понял суть вопроса?

именно

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

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

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

[GreatSnake]

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

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

[BRE]

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

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

QSettings::QSettings ( Format format, Scope scope, const QString & organization, const QString & application = QString(), QObject * parent = 0 )

Constructs a QSettings object for accessing settings of the application called application from the organization called organization, and with parent parent.

If scope is QSettings::UserScope, the QSettings object searches user-specific settings first, before it searches system-wide settings as a fallback. If scope is QSettings::SystemScope, the QSettings object ignores user-specific settings and provides access to system-wide settings.

If format is QSettings::NativeFormat, the native API is used for storing settings. If format is QSettings::IniFormat, the INI format is used.

If no application name is given, the QSettings object will only access the organization-wide locations.

[Igors]

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

[Гурман]

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

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

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

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

Код:

	QWidget* widget;
	QList<QWidget*> widgets = findChildren<QWidget*>();
	foreach( widget, widgets )
	{
		if (widget->inherits("QCheckBox"))
			connect(widget, SIGNAL(stateChanged(int)), this, SLOT(slChanged()));
		else if (widget->inherits("QComboBox"))
			connect(widget, SIGNAL(currentIndexChanged(int)), this, SLOT(slChanged()));
		else if (widget->inherits("QtColorPicker"))
			connect(widget, SIGNAL(colorChanged(const QColor &)), this, SLOT(slChanged()));
	}

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

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

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

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

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

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

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

[BRE]

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

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

[Гурман]

Например, можно было каждому объекту (виджету), который должен участвовать в проверке, добавить свойство.

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

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

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

[BRE]

Например, можно было каждому объекту (виджету), который должен участвовать в проверке, добавить свойство.

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

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

[Гурман]

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

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

[BRE]

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

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

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

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

[Гурман]

не согласен

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

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

[Igors]

   if (widget->inherits("QCheckBox"))
      connect(widget, SIGNAL(stateChanged(int)), this, SLOT(slChanged()));

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

Код

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

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

[BRE]

не согласен

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

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

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

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

[Гурман]

Igors

Стандартный путь лучше

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

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

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

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

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

BRE

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

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

Код:

if( sender()->specialWidget() )
	return;
changed = true;

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