Bug 37279

Summary:	calling startEditingAtNode(nodeobject) method of a tree control does nothing
Product:	LibreOffice	Reporter:	LRN <lrn1986>
Component:	Libreoffice	Assignee:	Caolán McNamara <caolanm>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	3.4.0 Beta5
Hardware:	All
OS:	All
Whiteboard:	target:3.7.0
i915 platform:		i915 features:
Attachments:	hanya's testcase for tree node editing hanya's patch to fix tree nore editing

Description LRN 2011-05-17 03:20:17 UTC

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.

Comment 1 LRN 2011-05-17 03:22:03 UTC

Created attachment 46796 [details] [review]
hanya's patch to fix tree nore editing

Comment 2 Björn Michaelsen 2011-12-23 12:03:30 UTC

[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

Comment 3 LRN 2011-12-23 23:05:20 UTC

Still present in 3.5.0-beta2

Comment 4 Michael Meeks 2012-05-08 06:52:54 UTC

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 ?

Comment 5 Not Assigned 2012-07-15 21:09:17 UTC

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

Comment 6 Caolán McNamara 2012-07-15 21:12:36 UTC

Resolved this by indeed basically making UnoTreeListItem inherit from SvLBoxString

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.