[Libreoffice] Fix an old bug 78701

LRN lrn1986 at gmail.com
Sat May 14 01:35:39 PDT 2011

This bug is almost 4-years old - 

   calling startEditingAtNode(nodeobject) method of a tree control does 

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 )
   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.

More information about the LibreOffice mailing list