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

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

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

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

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

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

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

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

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


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

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

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

именно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

угу, когда мало чего прописывать, можно и вручную, но когда только на странице настроек цветов 20 контролов, а страниц настроек полтора десятка...

а вот нет у меня такого ярлыка, и группы tools...

нашел designer.exe в qt/bin, запустил... фуфф... появился плагин колорпикер...

опять запутали... зачем нужен дизайнер на vc, если я работаю с mingw, и почему нельзя запускать в креаторе дизайнер на mingw?...

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

я потому и задаю здесь вопросы, что нигде нифига это не описано, а я спотыкаюсь там, где должен был бы легко

ну разумеется, vcproj в XML формате должен быть, а qmake нагенерил... обычный Makefile

не работает это... студия ругается, что созданный vcproj файл предназначен для предыдущей версии, пытается конвертировать и ругается, что не конвертируется

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

Тролли могли бы и файл проекта для студии положить...