QTableView and a row validation

[AlexVhr]

Hi!
I have usual MVC-setup (QTableModel descendant paired with QTableView descendant) and trying to do a row-based validation (field-based validation does not cut it in this case - validation is based on a combination of field values). So, the view calls model.submit(), the model validates the edited record, says 'no way' and returns False. But how do I tell the table view to return into editing state? The model does not know which view called it's submit() slot, if I understand correctly. Any thoughts?

[AlexVhr]

Allmost got it. I created a signal model.rowNotValidated(QModelIndex), which is emitted when model.submit() failes. Then I connected it to QTableView.edit() slot. It works well when a user presses Enter to submit edits, but does not work if a user ends editing by clicking on another row or elsewhere.

[wysota]

Isn't submit() a little bit too late to do validation? How about having a proxy model that accepts all crazy entries and does validation upon some signal from the view that the user changed the current row? Then you can decide whether to submit the data to the base model or not. And you have complete information about which row caused the failure.

[AlexVhr]

The validation per se is not a problem - how to deal with an usuccessful validation is. I know what row coused the failure (had to setup a simple tracking), so what I need is to signal TableView() - "Hey, it was all wrong, go back to editing state, row is not accepted."

I fail to see how a proxy model would be of any help in this case. After all, that proxy model would still be connected to TableView and I would still need to catch the moment editing is finished(with submit()), validate the input and return QTableView back into editing state upon usuccessful validation.

[wysota]

submit() does not mean that editing is finished. There can be cases when editing is finished but submit() is not called. I'm telling you to monitor QAbstractItemView::currentIndex() and when its row changes, start the validation.

[AlexVhr]

Actually, I've managed to ensure that submit() is called using QTableView.closeEditor(hint) - when user clicks away from the edited record, the hint == QAbstractItemDelegate.NoHint, in that case I call QTableView.closeEditor() with hint= QAbstractItemDelegate.SubmitModelCache. The problem is in the view - I need to reliably return it back to editing state

[wysota]

Doesn't calling edit() do what you want?

[AlexVhr]

For some strange reason - no. Actually, it does set the view into an editing state, but... it starts editing another row that user clicked to.

[wysota]

Are you passing a proper index to edit()?

[AlexVhr]

Yes, I am. Also, view's edit triggers are EditKeyPressed|DoubleClicked, so a single click should not trigger editing, so the editing is defenitely a result of a call view.edit(). But why does it start editing in a wrong place? Mistery.

---

Added after 30 minutes:

Oh, I was connecting my signal to another object, which happend to have a method called edit - imagine that. So no errors visible. A shame. But still - maybe it's time for me to give up trying to do it through Q..View.closeEditor() and go with something more reliable, as was recommended above. Are there eny examples of implementing record-based editing with record validation?