Bug 37279 - calling startEditingAtNode(nodeobject) method of a tree control does nothing
Summary: calling startEditingAtNode(nodeobject) method of a tree control does nothing
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.0 Beta5
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:3.7.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-17 03:20 UTC by LRN
Modified: 2012-07-15 21:12 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
hanya's testcase for tree node editing (12.50 KB, application/vnd.oasis.opendocument.text)
2011-05-17 03:20 UTC, LRN
Details
hanya's patch to fix tree nore editing (392 bytes, patch)
2011-05-17 03:22 UTC, LRN
Details

Note You need to log in before you can comment on or make changes to this bug.
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]
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