Problems with QItemDelegate

[Jimmy2775]

Why would it create an infinite loop? Do you call setData() from your code? If data is not modified, the signal should not get emitted, so if you "modify" already "modified" item, there is really no modification and no signal emition.

The objects I am editing can be edited in other GUI elements of the application as well. When the object is saved, it emits a notification to let all the GUI elements if the app know that the data has changed and they need to update. In the table, this notification is the dataChanged signal. If I use the corresponding slot for saving, then whenever the data is saved it will emit a dataChanged signal which will cause the data to be saved again which will emit another dataChanged signal which will cause the data to be saved again and so on...

I think you have a wrong approach. Instead of providing your own model mechanisms you should use the existing model-view framework to do all the work. If setData() is called, an item has been changed and it can be considered "dirty". You can tag it as such and when submit() is called, you can synchronise the model with the external backend if you use one.

The existing model-view framework is not sufficient to meet the needs of this application. Using the dataChanged() signal to cause the object to save will not work because the QTableView is not the only GUI element that can cause this signal to be emitted. Furthermore, a record can be considered "dirty" even if setData has not been called - it may have been modified by another part of the application or even another user using a different instance of the client but the same server, so I need my own isDirty mechanism. In a simple, stand-alone application I would agree that I'm taking the wrong approach, but in this case I don't have many options.

Essentially I am stuck in my save function that lies in the selectionChanged slot. From there I need to cause the delegate's setModelData function to be called somehow.

[wysota]

Why don't you use the model-view framework for other gui components as well? If all of them use QAbstractItemModel::setData() and all of them are connected to appropriate model signals (you might need to provide a kind of controller for that), all of them will get updated through the MVC framework. There is no sense in using the model-view pattern only for part of the data exchange -- either use it for all components or don't use it at all.

[Jimmy2775]

I would love to use the MVC framework for the entire application but as I have mentioned previously it is not sufficient to meet the needs of the application I'm working on.

There is no sense in using the model-view pattern only for part of the data exchange -- either use it for all components or don't use it at all.

I don't agree with that. I think it's important to try and leverage as much of Qt's out-of-the-box functionality as possible, and then extend it to fit any remaining requirements. We have had great success using Qt in this way.

In case anyone has this issue in the future, here's how I was able to fix the problem:

In the selectionChanged() slot, I was able to call the QItemDelegate's setModelData method. The reference to the deselected index from the QAbstractItemView's currentItem() method, and that index can be used to get the appropriate widget using the QAbstractItemView's indexWidget() method.

The answer that I was looking for was how to determine the state of the delegate editor, and this is found by checking QAbstractItemView::state() - this way I can ensure setModelData() is only called when the editor is open.

Thanks for all your help

[wysota]

I don't agree with that. I think it's important to try and leverage as much of Qt's out-of-the-box functionality as possible, and then extend it to fit any remaining requirements. We have had great success using Qt in this way.

You have a right to disagree, but the way you are implementing your app, you are trying to work-around main advantages of Interview, so you are really trying to find a solution "how not to use the model-view framework with the model-view framework".

In what way is Interview not sufficient for you? Because from the things you said, I can't see a point where it might fail.

[Jimmy2775]

In what way is Interview not sufficient for you? Because from the things you said, I can't see a point where it might fail.

No I don't expect you would - I haven't given much design detail because I wanted to solve my immediate problem and avoid debating design.

My application is a Qt client that connects to a DB server API written in Java. The objects I am modelling are actually pointers to Junc++ion wrappers. Qt is not sufficient for me because it doesn't allow the connected clients to monitor these Java objects and update the GUI whenever any one connected client modifies the object. Obviously this is not an issue with Qt because it was not designed to work this way, but it means I do have to, as you've said, work-around main advantages of Interview, in order to get the client to work properly.

I hope that is a satisfactory answer - I am reluctant to go into further detail to avoid violating NDA's and avoid debating design decisions beyond my control