[Qt-jambi-interest] Tracking down a problem in native-code

Gunnar Sletta gunnar at trolltech.com
Mon Nov 10 11:03:23 CET 2008


> Ok. So I'm better of using takeItem. I guess the same is true for:
> - QTableWidget:
>   Where I currently use #removeRow but should have used
>   #takeItem

No. If you read the documentation you see that there is difference.

removeItemWidget removes a custom widget that has been installed on an 
item using setItemWidget(), meaning the item is rendered using a 
checkbox or a combobox. You're not using this functionality hence the 
removeItemWidget call will just do nothing (except for the bug which 
does make it crash...), You can look at it as removeItemWidget removes a 
property from the item, but doesn't touch the item itself.

removeRow() removes all items in the row and is the correct function to 
use. In C++ the difference between removeRow and takeItem (besides that 
removeRow takes a full row, and takeItem goes item for item) is that 
remove will delete the items itself while take takes it out of the table 
without deleting it, making it possible to put the item into another 
table or extract data from it. In C++ the item is afterwards explicitly 
deleted. In Java, if you don't keep a reference to the taken item it 
will be GC'ed, hence the two functions will do mostly the same, with the 
subtle difference of which thread actually deallocates it.

> - QTreeWidget:
>   Where I currently use #removeItemWidget() and
>   QTreeWidgetItem#removeChild but should have used #takeTopLevelItem
>   and QTreeWidgetItem#takeItem

Same as for QTableView. removeItemWidget is wrong but you still can 
still use removeChild(). Same difference is between remove / take as for 
tables.

> When I currently completely refresh the List/Table/Tree structure I do a:
> - QTreeWidget#clear()
> - QTableWidget#clearContents()
> - QListWidget#clear()

These should be fine.

>> But... Going back to the actual problem, the native crash... The problem
>> is caused by the fact that we, when we mapped the API for QListWidget,
>> did the same assumption you did, namely that removeItemWidget() removed
>> the item. Under this assumption we de-reffed the instance, allowing
>> garbage collection for the item even though it was still referenced by
>> the QListWidget. GC would kick in and delete the item and if the GUI
>> thread accessed the item at this time, this would have caused the crash.
> 
> Maybe the JavaDoc should clarify this whole situation.

It was a bug, so I would rather just fix it, which I just did ;)




More information about the Qt-jambi-interest mailing list