[Kde-java] KListView and KListViewItem

[Richard Dale]

On Saturday 13 March 2004 10:13, Paul Sprakes wrote:
> > 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.
>
> You are correct, it works. Looks like something i'll have to keep my eye on
> in future.
>
> Thanks for your help.
No problem - but this is something that 'proper' documentation on the bindings 
would have helped with - I'm sorry there's only a couple of READMEs. 

Although, the ListViewItem and its delegate have been lost, it would still 
have been possible to cast the QListViewItem back to a KListViewItem with 
this method:

public static QtSupport dynamicCast(java.lang.String type,
                                    QtSupport source)

    'This member allows a typecast of an instance which wraps a Qt instance, 
to a more specialized type. Invokes the private qtjava.dynamicCast() via 
reflection, as that method isn't part of the public Qt api'.

Normally, you should only need to do that if you're trying to work round a bug 
in the bindings. There is a method 'QListViewItem::rtti()' that could be used 
to instantiate a more accurate wrapper class in cases such as your 
signal/slot handling. I'll try and add that to the runtime before the KDE 
3.2.2 release.

-- Richard