Hi there,
On Sat, 2011-05-14 at 12:35 +0400, LRN wrote:
> This bug is almost 4-years old -
> http://openoffice.org/bugzilla/show_bug.cgi?id=78701
Ho hum; so I read the bug, and I read the code - and I removed bogus
class, and a superstitious mis-understanding of the visibility
annotation. Having said that - unwinding exactly what is intended to be
exposed there is really hard.
Are there good docs ? what is this tree view control supposed to do ?
can we insert bitmap items into it ?
> calling startEditingAtNode(nodeobject) method of a tree control does
> nothing
Right - not ideal :-)
> checks that a tree item is a SV_ITEM_ID_LBOXSTRING and refuses to do
> anything with it otherwise.
Right - it does this because in
svtools/source/uno/treecontrolhelper.cxx:
class UnoTreeListItem : public SvLBoxItem
is not in fact an LBOXSTRING. Quite probably it should be - after all
we have some text.
So - as/when you can compile - I would suggest switching the code to
derive from SvLBoxString, and binning 'maText' in favour of
SvLBoxString's 'aStr' - and also junking the 'IsA' impl. - which should
then make things work for you :-)
> The simplest fix, as proposed in the original bug report, is to make
> UnoTreeListItem::IsA() return SV_ITEM_ID_LBOXSTRING instead of 0.
Yep - unfortunately the code then starts casting it to a 'SvLBoxString'
- which (might) work much of the time due to similar class layout ;-)
but is not a real fix.
Any chance you could look into that ? and/or where are you stuck with
building ?
Thanks !
Michael.
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
