This bug is almost 4-years old -
http://openoffice.org/bugzilla/show_bug.cgi?id=78701
Symptoms:
calling startEditingAtNode(nodeobject) method of a tree control does
nothing
What should happen:
Tree item editing should start. Depending on the implementation it
might look like a text control floating over the item, or the item
itself will turn into something editable; i don't know, since,
apparently, no one have ever been able to put a node in this mode.
What actually happens:
Nothing happens. isEditing() returns False after startEditingAtNode().
Why it happens:
As explained in the original bug report, this code ( void
SvTreeListBox::ImplEditEntry( SvLBoxEntry* pEntry ) in svtreebx.cxx):
...
for( sal_uInt16 i = 0 ; i < nCount ; i++ )
{
SvLBoxItem* pTmpItem = pEntry->GetItem( i );
if( pTmpItem->IsA() != SV_ITEM_ID_LBOXSTRING )
continue;
...
checks that a tree item is a SV_ITEM_ID_LBOXSTRING and refuses to do
anything with it otherwise.
However, this code (in treecontrolpeer.cxx):
sal_uInt16 UnoTreeListItem::IsA()
{
return 0;
}
returns 0 on any IsA() call to a tree item, so the check in
SvTreeListBox::ImplEditEntry never succeeds.
How to fix it:
The simplest fix, as proposed in the original bug report, is to make
UnoTreeListItem::IsA() return SV_ITEM_ID_LBOXSTRING instead of 0. It
should work because UnoTreeListItem is derived from SvLBoxItem.
Since i am unable to build LibreOffice from the source, i cannot
verify that this does fix the issue at hand and that it does not
introduce new issues.
Testcase is available in the original bug report.
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
