Deleting QTableWidgetItem and its affect on containing QTableWidget

[vharihar]

I'm doing a self-study of Jasmin Blanchette's book on "GUI Programming with Qt4". In chapter 3 when discussing the implementation of clipboard operations on the spreadsheet class, the book says, quoting:

The QTableWidget notices when its QTableWidgetItems are deleted and automatically repaints itself if any of the items were visible.

Where is this aspect documented? I don't see it documented in Qt Assistant in the documentation for QTableWidgetItem nor for QTableWidget.

The implementation also seems to imply that when we delete a QTableWidgetItem object we needn't worry about any dangling pointers in the containing QTableQWidget object, etc. I'd be more comfortable if such aspects were explicitly documented. Or am I not looking at the right place?

[JonB]

@vharihar
These statements are true, whether they are documented or not. In general this comes under Object Trees & Ownership. The docs for, say, QTableWidget::setItem also mention

The table takes ownership of the item.

and whenever you see that sort of statement that is telling you it will look after deletion.

[VRonin]

I agree with OP, this is undocumented and an implementation detail. It works because ~QTableWidgetItem() calls model->removeItem(this); but I would consider a nice fail-safe rather than the base case.
If you want to open a ticket tag me please and I'll submit a doc fix patch when I have a minute

[vharihar]

@JonB, @VRonin , thanks a lot, what you say makes sense.

Dear @VRonin, if you want me to file a ticket I will. Though by looking at your explanations, it doesn't seem to be a doc bug. I guess the source of my misunderstanding was the fact that I wasn't aware of the object tree and construction/destruction details.

While at the topic of doc issues, there perhaps is another issue as regards QTableWidgetItem.text(). Per the same book by JB and MS,

text()

is the equivalent of calling

data(Qt::DisplayRole).toString()

This behavior doesn't seem documented in Qt Assistant either.

[JonB]

@vharihar
Again, maybe @VRonin will disagree with me, but while that is indeed true I don't see why it should be documented particularly. There may be loads of dedicated methods which map one-to-one with data(someRole), once you understand how data() works and roles. Wouldn't you expect text() to return this, what else should it return?

[vharihar]

@JonB Well, for someone who isn't intimately familiar with the design of Qt classes (nor the thought process behind them), I would expect this aspect to be documented. Why leave one guessing and wondering?

Or conversely, just as you pointed me to a link that describes object trees and construction/destruction, is there a link that describes "how data works and roles"?

I couldn't find it in Qt Assistant when looking at the documentation for QTableWidgetItem.

Pardon me if my question is still silly, quite possible :-), as I'm still a newbie with Qt.

[JonB]

@vharihar
I wouldn't. Many methods will call other methods. that's all this is doing. To do what you want every single method would need to describe every other method it calls. I have never seen any API which documents to that level of detail.

[VRonin]

@vharihar said in Deleting QTableWidgetItem and its affect on containing QTableWidget:

I guess the source of my misunderstanding was the fact that I wasn't aware of the object tree and construction/destruction details.

QTableWidgetItem is not a QObject so that concept doesn't apply

@JonB said in Deleting QTableWidgetItem and its affect on containing QTableWidget:

I don't see why it should be documented particularly

I view QTableModel (the private class behind QTableWidget) as a container of QTableWidgetItem, a fancy version of QVector<QTableWidgetItem*> itemVector;. The fact that this code:

QTableWidgetItem* firstItem = itemVector.at(0);
delete firstItem;

Actually removes the item from the vector rather than leaving a dangling pointer behind to me is non-trivial. While it's a nice feature, if the docs don't guarantee me this is the case it should be considered an implementation detail that can change. This behaviour is not even auto-tested so nothing is stopping the change.

[JonB]

@VRonin
I bow to your knowledge on the QTable... front. But the conversation has now moved onto the OP would like QTableWidgetItem.text() to require documenting in terms of data(). And presumably so on for each further method he comes across....

[VRonin]

@JonB said in Deleting QTableWidgetItem and its affect on containing QTableWidget:

would like QTableWidgetItem.text() to require documenting in terms of data(). And presumably so on for each further method he comes across

I see, I take the opposite view in this case. the fact that text and data are connected is an implementation detail that should not form part of the library-user contract