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.