Created attachment 46795 [details] hanya's testcase for tree node editing This bug is almost 4-years old - http://openoffice.org/bugzilla/show_bug.cgi?id=78701 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.
Created attachment 46796 [details] hanya's patch to fix tree nore editing
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Still present in 3.5.0-beta2
Just to update the bug; the patch was reviewed on the list a while back, and doesn't work: > 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 ?
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa3eeb28bcba10d603c15ee850620bed638514f5 Resolves: fdo#37279 and #i78701# startEditingAtNode does nothing
Resolved this by indeed basically making UnoTreeListItem inherit from SvLBoxString