QAbstractItemModel with QUndoStack

[wysota]

The undo / redo commands would use the standard model interface or some added custom interface so that the model would emit dataChanged and make use of beginInsert... etc.

Ok, but if you use setData() in your app that creates a QUndoCommand which calls setData again, you'll have an endless recursion. Use of custom methods is a solution here of course.

The problem for me is how to implement this. I have a filtered table view on the model and a configurable number of widgets using a QDataWidgetMapper.

Well, in that case it'd be hard to do it this way.

[No-Nonsense]

Ok, but if you use setData() in your app that creates a QUndoCommand which calls setData again, you'll have an endless recursion. Use of custom methods is a solution here of course.

This is wy I thought of either the custom methods or to use a custom role for undo/redo. E.g. the model is modified from the outside using setData(..., Qt::EditRole) and undo/redo use setData(..., UndoRedoRole) so i would not create a undo command when accessed using the UndoRedoRole.

But then my problem remains: Would I prevent the first call to redo (i.e. have it do nothing) to be able to return false from setData or would I return true, even if nothing was changed (because the created undo command failed changing the data in redo).

-Jens

[wysota]

If changing the model is a cheap operation, I would ignore the situation and let the model set the data to what it was before.

BTW. Monitoring the EditRole might not be enough - depends on the model and how versatile you want your solution to be.

[maximAL]

hi,
following the same issue i thought it might be feasible to use a proxy model for that. this, of course, would offer reusability and reduce the complexity of the actual model greatly.

now, 2 problems come to my mind:
1) signal connection. when undoing, the source model's events shouldn't be added to the undo stack. a simple, but somewhat hacky approach could be to just disconnect from the source model while undoing.
2) undoing insert/remove item events. i guess the structure of the model had to be parsed, eg. the cols/rows upwards from a removed item, to insert it back again at this very positions. seems also a little hacky...

am i missing some points that could turn out to be problematic?

[doecz]

You could add to your model private section friend class SetDataCommand. Then can call protected function of model in the SetDataCommand.