[Kde-java] KListView and KListViewItem

[Richard Dale]

On Friday 12 March 2004 20:21, Paul Sprakes wrote:
> I have subclassed KListViewItem with a class that takes a delegate object
> which I can inspect when I catch the various signals from KListView. I have
> found though that while items added as children to KListView will come
> through the signal mechanism as the correct subclass, items added as
> children of a ListViewItem always come back as QListViewItem. I cannot cast
> the QListViewItem items back into my subclass and there is no way for me to
> get any info about what has been selected other then the displayed text.
>
> Can anyone shed any light on this or tell me what I am doing wrong?
>
> //this is connected to the "executed(QListViewItem)" signal
> public void treeItemSelected(QListViewItem item) {
> 	System.out.println(item);
> }
>
> private void populateServerTree() {
>   Iterator servers = app.getServers().iterator();
>   while(servers.hasNext()) {
>     NewsServer server = (NewsServer)servers.next();
>     ListViewItem serverNode = new ListViewItem(tree,
> server,server.getHost()); Iterator groups =
> server.getSubscribedGroups().iterator();
>     while(groups.hasNext()) {
>       NewsGroup group = (NewsGroup)groups.next();
>       ListViewItem groupNode = new ListViewItem(serverNode, group,
> group.getName());
>     }
>   }
> }
I think what might have happened here is that the ListViewItems that appear as 
QListViewItems have been garbage collected. However, the C++ underlying 
instance wouldn't have been deleted as it was still in the QListView tree 
with an 'owner' C++ instance. Then, when the signal was emitted the qtjava 
runtime looks for a java instance corresponding to the C++ one, but it 
doesn't find one, and instantiates a new QListViewItem instance.

A work round might be to create an ArrayList and add each ListViewItem to 
that, and then there would always be a live references and java wouldn't 
garbage collect them. I would be interested if that fixes it.

-- Richard