"так" тоже будет сообщение об ошибке в файле настроек

key\параметр=@Invalid()

при том, что лист точно правильно сформирован


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

у меня есть QStringList который может быть разного размера, надо записывать его в файл, создаваемый объектом класса ::QSettings

показалось, что это несложно сделать, есть даже такой метод QList<QVariant> QSettings::value(name).toList() который сразу возвращает список, его уже в QStringList элементарно

но как записывать целиком QList<QVariant> чтобы его можно было потом с помощью toList получить - не видно, если попытаться тупо написать QSettings::setValue("list", list ) то в файл записывается Invalid

да просто "dll должна быть доступна при запуске исполнимого модуля" это такая же аксиома, как "у байта 8 бит", и странно когда разработчики такие ляпы допускают...

я про свои объекты говорил, которые Qt мало где наследуют...

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

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

кхм... а я почти никогда не захватываю такими мелкими кусками  - у меня стратегия такая, оптимизация расхода, стараюсь, если захватывать, то кусками не менее 256К

так что, дело не везении 

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

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

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

после удаления объекта занятая им память возвращена в system pool, и уже не принадлежит приложению, выделенный ранее сегмент удален из соответствующей таблицы, поэтому любое обращение к удаленному объекту - это обращение к объекту вне приложения, следовательно segfault

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

а работу exception достаточно проверять (int*)0 = 0; 

пссс... ну разумеется, exe к dll компоновщик привязал, а при старте она не загружается, потому как ее нигде не видно, и IDE тут ни при чем - для креатора укажите DESTDIR в .pro создания dll чтобы она сразу ложилась туда же, где exe создается

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

поэтому в качестве примера самой dll можно использовать любую dll из комплекта Qt

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

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

все, что читаю по этому поводу - либо вариант установить параллельно еще один Qt, либо получается замена имеющегося динамического на статитческий (правятся конфигурационные файлы, перегенерятся библиотеки)

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

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

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

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

Igors

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


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

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

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

BRE

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


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

не согласен

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

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

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

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