ListCtrl.SetItemData() requires a int value as item data (long in C++).
I've seen that since wxwidgets 2.8.4 there's a new method: ListCtrl.SetItemPtrData()[1] that can receive a pointer instead of a long int.
I guess SetItemPtrData() could be available to wxpython in order to allow a python object as item data... from my profane point of view, could wxpython SetItemData() be wrapped to C++ SetItemPtrData()? This way would be better for API consistence...
The problem is that the listctrl doesn't take ownership of the pointed to object and so it doesn't manage deleting it when the item is deleted or the listctrl is destroyed, so there is no hook available for me to DecRef the Python object pointer stored there. So we either risk holding pointers to Python objects that may or may not still exist, or we have reference leaks.
The treeCtrl does allow branches to point to arbitrary Python objects to be pointed to via SetPyData(item, obj). Seems like it would have the same problem wouldn't it?
ListCtrl.SetItemData() requires a int value as item data (long in C++).
I've seen that since wxwidgets 2.8.4 there's a new method: ListCtrl.SetItemPtrData()[1] that can receive a pointer instead of a long int.
I guess SetItemPtrData() could be available to wxpython in order to allow a python object as item data... from my profane point of view, could wxpython SetItemData() be wrapped to C++ SetItemPtrData()? This way would be better for API consistence...
The problem is that the listctrl doesn't take ownership of the pointed to object and so it doesn't manage deleting it when the item is deleted or the listctrl is destroyed, so there is no hook available for me to DecRef the Python object pointer stored there. So we either risk holding pointers to Python objects that may or may not still exist, or we have reference leaks.
The treeCtrl does allow branches to point to arbitrary Python objects to be pointed to via SetPyData(item, obj). Seems like it would have the same problem wouldn't it?
Similar but not the same. The C++ wxTreeCtrl doesn't deal with raw pointers, but allows you to store instances of the wxTreeItemData class, and it takes ownership of the data object (meaning that it uses the delete operator on it when the item is destroyed.) This allows me to derive a class from wxTreeItemData that can hold a PyObject pointer, and properly call Py_INCREF() and Py_DECREF() on it so the Python memory management rules are satisfied.
Until the C++ wxListCtrl is updated to do something similar then the best I can do is allow you to store integers as it does now. Without any internal memory management of the associated pointer items I have no way to reliably maintain correct reference counts on stored Python objects without adding some overhead for every item in every listctrl that everybody would have to live with even if they don't associate Python objects with their list items.
ยทยทยท
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!