Problems with QItemDelegate

[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