Qt Property Browser library - notice on edit conclusion

I'm using the QtPropertyBrowser library from the qt-solutions archive. It seems that the only signals I can find to connect to inform me whenever a key is pressed within the LineEditor attached to a string property. I want to find out when the user has CONCLUDED their edits by going to the next item or by hitting the enter key.

How can this be done?

the answer may be noway. I think you can not get this "CONCLUDED" signal. but you can hack the source code.
look the following code from qttreepropertybrowser.cpp.

Code:

---

181 void QtPropertyEditorView::keyPressEvent(QKeyEvent *event)
 182 {
 183     switch (event->key()) {
 184     case Qt::Key_Return:
 185     case Qt::Key_Enter:
 186     case Qt::Key_Space: // Trigger Edit
 187         if (!m_editorPrivate->editedItem())

---

and

Quote:

---

qteditorfactory.cpp:1533: void focusInEvent(QFocusEvent *e);
qteditorfactory.cpp:1649:void QtCharEdit::focusInEvent(QFocusEvent *e)
qteditorfactory.cpp:1653: QWidget::focusInEvent(e);
qtpropertybrowserutils.cpp:399:void QtKeySequenceEdit::focusInEvent(QFocusEvent *e)
qtpropertybrowserutils.cpp:403: QWidget::focusInEvent(e);
qtpropertybrowserutils_p.h:147: void focusInEvent(QFocusEvent *e);

---

just a tip.

Quote:

---

Originally Posted by xiaokui

the answer may be noway.

---

Yeah, I believe you are correct. The lineedit factory connects the the change signal to the textEdited signal in the LineEdit. It's an unfortunate choice. Further, it seems the developers spent a lot of time and effort making it impossible to extend these factories in order to make minor behavioral changes. You not only have to write your own, you have to write all the crap in their template that tracks things.

I did manage to get MOST of the behavior I want by changing the library to instead connect to the editingFinished signal and then forwarding the string information to the original function that connected to textEdited. Unfortunately I'm not getting the ESC reverts behavior that is common to this kind of control. Looks like in order to get basic, standard behavior I have to write a whole new thing that uses a subclass of LineEdit which generates new signals to revert or something. The function you pointed out might be well worth looking at though and maybe there's an easier answer in editing it.

Thanks. I was beginning to think this forum didn't have anyone that got it.

You are doing it all wrong. There is QtAbstractPropertyManager::propertyChanged() signal which should be the only thing interesting for you. Other than that there is QtAbstractPropertyBrowser::currentItemChanged() signal if you want to do it at the widget level.

Quote:

---

Originally Posted by wysota

You are doing it all wrong.

---

This person doesn't know what they are talking about. Neither of the signals they mention do anything even close to what I specifically say I need. The former responds to any change in text DURING edits (exactly what I do NOT want) and the latter is only generated when the user changes the item they're focused on and thus doesn't respond to ENTER nor to ESC.

Either they don't know anything about the library or they're quite purposefully being a jerk. More likely the latter given the unwarranted arrogance and attitude.

Being rude will not get you even an inch closer to a solution. Reimplement QtAbstractPropertyBrowser::createEditor() of the property browser you are using and then you can connect to any signals in the editor that you want. Just remember that not every property is edited by a QLineEdit.

Quote:

---

Originally Posted by wysota

Being rude will not get you even an inch closer to a solution. Reimplement QtAbstractPropertyBrowser::createEditor() of the property browser you are using and then you can connect to any signals in the editor that you want. Just remember that not every property is edited by a QLineEdit.

---

You're the one being rude. You're also adding absolutely nothing to the conversation. If you'd like to utterly ignore everything I ask I'd be quite happy. You don't seem to even know C++ very well, having once told me to try to #ifdef wrap a class in order to pragmatically create it, and now trying to send me down wild goose chases. I don't particularly appreciate it.

---

Added after 6 minutes:

More info for those that have run into the same problem and may be searching this forum.

The right answer may have more to do with modifying the library itself. An item delegate is used and that whole system of objects is BUILT to provide the behavior I'm looking for. The propertybrowser library methodically breaks that behavior by inserting overrides to things like setModelData() that break the behavior. After stepping through the handlers it became clear that the ESC vs. RETURN key stuff is already being handled way up the tree in Qt and the difference in how is whether or not this function is called.

After doing a quick test by modifying that function to result in an emit of a new signal I added to the tree property browser it begins informing me exactly like I want it to. The main issue now is in discovering how this should have been done so that the property goes back to its previous value when the editor is closed and commit was never initiated.

I'll continue to inform about progress but I'm moving over to the SO question I made for this topic. The signal to noise ratio is much lower over there.

http://stackoverflow.com/questions/4...hanged-signals

Quote:

---

Originally Posted by nroberts

You're the one being rude. You're also adding absolutely nothing to the conversation. If you'd like to utterly ignore everything I ask I'd be quite happy. You don't seem to even know C++ very well (...)

---

Yes, of course, I'm the one being rude :)

Decided to go ahead and paste directions for a fix here too:

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, and the LineEditor's createEditor function has to be edited to remove the connection to textChanged(). To get the correct behavior the property has to remain unchanged until the commitProprty() request is made.

Hello Roberts,

I had passing through all the problems that you described here. Since the beggining when I was looking for a solution the search always bring me here to this topic. It seems that is the only place in the whole internet that have usefull information about QtPropertyBrowser.

The problem of the behavior of the ESC key was not the hardest problem that I had to solve, since I was working a lot in the events to make the browser works for other tasks, but still is not an easy solution.
The class QtPropertyEditorDelegate creates the editor and install an event filter, so you can catch the ESC event here:

Code:

---

bool QtPropertyEditorDelegate::eventFilter(QObject *object, QEvent *event)
{
    if ( e->key() == Qt::Key_Escape ) {
        QtProperty* property = m_editorPrivate->currentItem()->property();
        property->propertyManager()->abort(property);
    }
 
    return QItemDelegate::eventFilter(object, event);
}

---

In my case I used the property manager to handle with that. But you need to set the old value in the editor and not in the model, since you will let the event propagates and the QItemDelegate will worry about the post events and the behavior of the grid.

I know that it is too late to help you but maybe it can help someone.