Bug 39589 - XLS files saved by Calc all have split window / or give security Warning when opening in Excel (FILESAVE)
Summary: XLS files saved by Calc all have split window / or give security Warning whe...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard: target:3.5
Keywords: regression
Depends on:
Blocks: mab3.4
  Show dependency treegraph
 
Reported: 2011-07-27 02:22 UTC by Chris Morgan
Modified: 2012-06-07 01:26 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Empty xls file saved by Calc, and Excel screenshot showing splitter (9.71 KB, application/x-zip-compressed)
2011-07-27 02:22 UTC, Chris Morgan
Details
Sample spreadsheet and screen shots of Calc and Excel (281.05 KB, application/zip)
2011-10-16 09:16 UTC, NoJoy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Morgan 2011-07-27 02:22:08 UTC
Created attachment 49608 [details]
Empty xls file saved by Calc, and Excel screenshot showing splitter

If a spreadsheet is saved from CALC as MS Excel 97/200/XP (xls) format,
or MS Excel 2007 (xlsx), then when opened in MS Excel, the spreadsheet has 
a split window hiding the top row-letter labels. This split window was
not included in the original document, and does not appear when the XLS
file is re-opened in Calc.

I only have MS Excel 2000 to test this with (including the compatiblity pack
for opening XLSX files). I have verified that the problem occurs on 3 different PCs, but can somebody verify that the problem occurs when opening in later versions of Excel as well?

To reproduce:
Open Calc, save empty spreadsheet as XLS format (Microsoft Excel 97/2000/XP (*.xls).
Then open the saved XLS file in Excel - the row labels are hidden by a window split bar which was not in the empty spreadsheet saved by Calc.

See attached zip file, includes empty XLS file saved by Calc, and screenshot of how it appears when opened with MS Excel 2000:
Comment 1 Chris Morgan 2011-08-18 01:48:49 UTC
Just tested with LO V3.4.2 and LO V3.3.4

This bug is not present in V3.3.4
The bug has been introduced since then.
Comment 2 Tom 2011-08-18 05:52:05 UTC
Hi :)
The 3.3.x branch is developed alongside the 3.4.x branch.  

The 3.3.x seems to generally be the stable branch aimed at corporate users and people that want to avoid upgrading often.  There are bigger gaps between releases presumably to allow more alpha&beta testing to ensure the release is more stable.  

The 3.4.x seems to be more like a development branch "for early adopters" and tends to have a lot of new features (such as better .doc and .xls compatibility apparently) so a lot of people prefer it.

As it happens the 3.3.4 was released more recently than the 3.4.2.  

A lot of OpenSource projects work this way so it makes sense.
Regards from
Tom :)
Comment 3 Cor Nouws 2011-08-18 13:53:32 UTC
Hi Chris.

I tested with a file from 3.4.2 and one from 3.3.3
Opened in Excel 2010
The second doesn't give a problem.
The first does - it does show the row headers, contrary to your situation, but  in stead it gives a security warning :-)
So my guess would be that there is something with the xml format.. or such.
Something we need to investigate further...
Comment 4 Chris Morgan 2011-08-19 02:54:58 UTC
(In reply to comment #3)
> Hi Chris.
> 
> I tested with a file from 3.4.2 and one from 3.3.3
> Opened in Excel 2010
> The second doesn't give a problem.
> The first does - it does show the row headers, contrary to your situation, but 
> in stead it gives a security warning :-)
> So my guess would be that there is something with the xml format.. or such.
> Something we need to investigate further...

Hi, that's interesting. I have now tried using the Microsoft Excel Viewer (2007? V12 - version is not very obvious) on Windows 2000 to open my blank XLS spreadsheets created with LO 3.4.2 and LO 3.3.4, and I see exactly the same behaviour as I first reported.

3.3.4 save blank XLS file - opens OK in MS Excel Viewer
3.4.2 save blank XLS file - opens with extra splitter at the top

cheers,

Chris
Comment 5 domi 2011-09-15 05:56:49 UTC
reproductible in all 3.4.x version
REGRESSION fom 3.3.x

save without error if xls file opened with 3.3.4
no error if reopening with normal excel 2003 (not the viewer)

save always with errorS if xls file opened with 3.4.3
and reopen with excel 2003 => 3 errors
* security error (excel autocontrol from winupdate patch)
* split windows 
* column header reduced to 0 high size   (a,b,c,... column-label hide..)
Comment 6 NoJoy 2011-10-16 09:16:41 UTC
Created attachment 52381 [details]
Sample spreadsheet and screen shots of Calc and Excel
Comment 7 NoJoy 2011-10-16 09:18:27 UTC
So far LibreOffice 3.4.3 has been excellent, but I see the same problem on both my XP and Win7 machines.

Attached is an .xls file created by LO Calc and Saved As MS Excel 97/2000/xp/2003.... see screen shot 

"LO Calc 3.4.3 Screen.jpg" --- everything OK.

Then open the .xls file in MS Excel XP (2002) --- note missing column headers (i.e., A, B, etc)... see 

screen shot "Office Excel XP Screen 1.jpg"

Then with the file still open in MS Excel, click on Windows command on toolbar --- note "Remove Split" 

option is available... see screen shot "Office Excel XP Screen 2.jpg"

My obvious workaround that appears to work is to (1) drag down top of spreadsheet to expose hidden 

column headers, and (2) remove the split windows.

Hopefully this will be fix in an upcoming release.
Comment 8 Mikeyy - L10n HR 2011-10-29 06:33:01 UTC
+1 for this bug
Was hard to find under which name was this bug reported!
Please fix it, few of us in our company is using LO, others using Excel 2003 and it's annoying.
Comment 9 Rainer Bielefeld Retired 2011-10-29 09:37:01 UTC
Not unexpected: still reproducible with parallel installation of MinGW Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  2ba5d12-e8c71c5-41e7bcd-4b83b90)] (daily/MinGW_cross-compilation2011-10-25_00.12.09)"
Comment 10 Kohei Yoshida 2011-11-23 13:09:43 UTC
So, this is only reproducible with the Windows version; the Linux version generates correct xls file.

I'm looking into this as we speak.
Comment 11 Kohei Yoshida 2011-11-23 15:50:00 UTC
Fixed on master.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0215f8b19451ab67c7fdaf91f2da8298a9b89c47

It was due to some "smart" type-casting being not so smart when casting a signed int into an unsigned one.  The fact that it worked on Linux may have to do with the fact that I build 64-bit version on Linux, whereas for Windows we only build 32-bit version (hence the size and range of the long integer types are different).