QtPropertyBrowser and value changed signals

Question

I'm using the Qt Property Browser library as a record editor. When the user has completed their edits of any given field, by removing focus from the edit item or pressing the enter key, I want to be informed of that so that I can take the change, process it, and send it off to the REAL item that's being changed.

Unfortunately I seem to only be able to find the propertyChanged and valueChanged signals and they get triggered every time any amount of text is added or removed, not just when the user is triggering a finish.

Without being able to get this notification I don't see how this can be a usable component. It doesn't even revert when the user hits [ESC], which I certainly need to be able to implement! Surely I must be wrong about there being absolutely NO signal that does what I need, but I sure can't find it.

Anyone know?

---

Upon examining the source code, the people who made the line editor factory made the unfortunate decision to connect with textEdited rather than editingFinished. It would be a relatively simple matter to change except that the quite methodically made it impossible to extend this editor factory that has an extensible interface!

ALL I would need to do is override the createEditor function, disconnect the bad connection, connect a better connection with a call in between to get the string out of the line edit control. But NO!!! We're not going to let you do that! We're going to put all of the accounting stuff in a private class you can't access or call and those parts that we are going to let you call are going to be tightly coupled to the fact that they're being called by the edit control, NOT by anything else. ERGO, we've quite effectively made life as frustratingly impossible as we could possibly imagine. Aren't we brilliant?

---

I've found out more. The standard Qt approach for these kinds of objects uses delegates to control the behavior I'm trying to get. The Qt property library overrides this behavior and does something else that is NOT what I'm trying to accomplish. Inside of the QAbstractItemDelegate interface is a setModelData function that is called by the view it's attached to when the user commits their edits; it is not called when they destroy the editor without committing.

The next trick is going to be learning the Qt Model/View architecture and patching the library to do it the right way. This may even amount to no more than simply removing the overriding stubs that destroy the behavior I'm trying to get. It might also be that forgoing the use of this system in place of simply using the QtTreeView might be a better choice though it would be nice to be able to retain the ability to switch out between the different kinds of browser.

Answer 1

So, here's the half-ass fix I came up with:

I added a "commitItem(QModelIndex)" function to the private thing in the TreePropertyBrowser. Then I call that from the delegate when the setModelData() function is called.

This then finds the property, calls a new function I added to the AbstractBrowser to fetch the factory for a property and then tells the factory to "commitProperty(QtProperty*)".

This function is an empty virtual at the base and in the LineEditFactory I override it to apply the property change, which generates the valueChanged() signal.

With these changes in place the user is able to back out of the edit by hitting the ESC key and I get notified iff they commit the property change by hitting RETURN, focus changing, etc...

Only works for the tree version at the moment. Probably won't bother trying to make the rest work. In fact I'm probably going to throw this library away and just use the QTreeView myself. IT behaves the way I want, this thing had to be uber-hacked to get the behavior BACK.

Oh yeah, you also have to remove the connection to the textChanged() signal in the LineEditFactory's createEditor().

Answer 2

I ran into this same problem awhile ago. We needed to know when editing was finished for any of the QVariant editors. The trick is that the framework creates and deletes its widgets as you start and stop editing. So, buried in the EditorFactory classes, I connected to QObject::destroyed signal very every single QWidget type it creates, and bubbled up a new propertyEditFinished signal that the main app can catch.

QtPropertyBrowser is definitely crazy, but it's also a pain to reimplement the whole thing.