Bug 41534 - FILEOPEN: libreoffice silently drops cell value in .xlsm files if originally on a tab with an embedded space in the name
Summary: FILEOPEN: libreoffice silently drops cell value in .xlsm files if originally ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.3 release
Hardware: x86 (IA32) Linux (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-06 11:14 UTC by m_v
Modified: 2014-10-07 17:46 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
This is the file that illustrates the behavior. (10.76 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2011-10-06 11:14 UTC, m_v
Details

Note You need to log in before you can comment on or make changes to this bug.
Description m_v 2011-10-06 11:14:37 UTC
Created attachment 52053 [details]
This is the file that illustrates the behavior.

We've noticed that with .xlsm files created with Microsoft Office 2010, if
there is an embedded space in the tab name, Calc will silently discard that
value.  I'm attaching a file to illustrate this problem.

The first row of numbers are linked to a file named test.xlsm, which
you don't need to have around for testing, as office knows to use the
last available value and not update the link.  test.xlsm has three tabs:
tab1, tab_2, and "tab 3".

The second row links to a file "test with spaces.xlsm", same idea.


Microsoft Office 2010, display user.xlsm:

----------------
link to test:
1       2       3


link to test with spaces
1       2       3
----------------

Libreoffice 3.3.3, display user.xlsm:

----------------
link to test:
1       2


link to test with spaces
1       2
----------------
Comment 1 Markus Mohrhard 2011-11-03 14:38:28 UTC
at least in a master build the cell content is still there but not correctly displayed
Comment 2 Björn Michaelsen 2011-12-23 12:35:43 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 Frank Tilley 2012-03-30 13:58:20 UTC
The problem persists; I tried both 3.5.1.2 and the beta/prerelease 3.5.2.2 

(In reply to comment #2)
> [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 4 Frank Tilley 2012-07-09 17:50:49 UTC
Has there been any further work on this bug?

frank
Comment 5 Teo91 2013-09-30 13:40:06 UTC
This bug is no more with LO 4.1.1 on Windows 7 SP1: 
Calc correctly shows the .xlsm as in Excel 2010, all 3 values are visible.

But the bug was reported under Linux: can anyone confirm it's no more?
Comment 6 Buovjaga 2014-10-07 17:42:43 UTC
Works OK for me.

Version: 4.3.1.2
Build ID: 4.3.1.2 Arch Linux build-1
Comment 7 Teo91 2014-10-07 17:46:35 UTC
Thank you @todventtu.

This bug is no more also with LO 4.2.6.2.

Set to WORKSFORME.