Oh, I see now. In that case I think your tactic of writing your own class using the QSettings API is a good one.Originally Posted by jrideout
Oh, I see now. In that case I think your tactic of writing your own class using the QSettings API is a good one.Originally Posted by jrideout
Unfortunately simply subclassing QSettings won't help you because none of its methods are virtual. I think you should just implement a class simmilar to QSettings and substitute all occurences of QSettings in the code. Of course your class can still use QSettings to provide compatibility with the "usual" settings storage methods.
Originally Posted by wysotaThanks, I didOriginally Posted by jrideout
Right but there is a static method called registerFormat() that allows the creation of custom settings format without changing anything in the API, just implementing to functions...Originally Posted by wysota
Current Qt projects : QCodeEdit, RotiDeCode
But, registerFormat() assumes that the format is of a file on the hard disk, you can't change that, of course you could set the file to /dev/null, or something but you'll have all sorts of issues or at least lost functionality with the conflict/locking stuff that Qsettings uses, plus it really isn't designed for it.Originally Posted by fullmetalcoder
What I wanted was to store the data in a database, regardless of format (meaning I don't care about the format, not I want a generic use any format class). To do that I implemented a new (not derived) class which has a similar, but not entirely same api as QSettings, this enabled me to migrate a very large codebase over a day or so.
Bookmarks