Issue 119337 - xlsx import with chart is not displayed
Summary: xlsx import with chart is not displayed
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: 3.4.0
Hardware: Mac Mac OS X 10
: P3 Major (vote)
Target Milestone: 3.4.1
Assignee: AOO issues mailing list
QA Contact:
Keywords: regression
: 120369 (view as issue list)
Depends on:
Reported: 2012-05-11 22:59 UTC by matthew
Modified: 2012-07-26 11:20 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 3.4.1_release_blocker+

Example xlsx file with chart. (7.47 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-05-11 22:59 UTC, matthew
no flags Details
PNG of what is shown in OpenOffice vs Excel (116.39 KB, image/png)
2012-05-11 22:59 UTC, matthew
no flags Details
Solves the wrong get/setPropertyValue calls in SvxShapeText (and thus in SvxOle2Shape) (2.67 KB, patch)
2012-05-30 08:54 UTC, Armin Le Grand
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description matthew 2012-05-11 22:59:01 UTC
Created attachment 77531 [details]
Example xlsx file with chart.

Opening the attached xlsx file in Apache OpenOffice 3.4.0 on Mac OS X does not display the chart. You just get a box with "OLE" Icon inside it.
I have also attached a screen capture which compares what is seen in excel vs open office. The chart is properly display in OpenOffice 3.3.0.
Comment 1 matthew 2012-05-11 22:59:40 UTC
Created attachment 77532 [details]
PNG of what is shown in OpenOffice vs Excel
Comment 2 zhao xia 2012-05-23 07:10:02 UTC
I can't reproduce this issue againt Windows XP platform
Comment 3 zhao xia 2012-05-24 01:45:27 UTC
Which build you are using? I can't reproduce it on Mac platform as well.
Comment 4 matthew 2012-05-24 02:35:10 UTC 3.4.0
AOO340m1(Build:9590) - Rev. 1327774
2012-04-19 03:33:29
Comment 5 Andre 2012-05-24 12:26:42 UTC
I can reproduce the issue on MacOSX (10.7.3) on a freshly build office.  Only the OLE replacement icon is shown where the chart should be.
Comment 6 Andre 2012-05-24 13:33:26 UTC
Tried different versions:

It is OK on OOo 3.3 and 3.4 beta.  It is broken on AOO 3.4.
Comment 7 Armin Le Grand 2012-05-24 16:02:02 UTC
ALG: I get the following assertions:

Error: Disconnect() called on disconnected object!
Error: PropertySet::implSetPropertyValue - cannot set property "CLSID" From File /Users/armin_le_grand/aoo/svn_trunk10/main/oox/source/helper/propertyset.cxx at Line 171
Error: No embedded object is given! From File /Users/armin_le_grand/aoo/svn_trunk10/main/sc/source/core/data/documen5.cxx at Line 752
Comment 8 Armin Le Grand 2012-05-24 16:24:12 UTC
ALG: Line 752 is the note that the OLE is not found, the problem is more line 171. It looks like the property CLSID cannot be set at import time (it contains the unique identifier for the Ole to load). This can go wrong when either the value in the given any is not of the expected type or the slot for CLSID is not allowed. Need to check deeper, I do not know too much about PropertySets.
Comment 9 zhao xia 2012-05-25 08:15:19 UTC
Improve the priority to P1 and move this defect to AOO35 as AOO 350 candidate
Comment 10 Olaf Felka 2012-05-25 08:32:34 UTC
This is not a P1 issue! AOO won't get unusable by this problem. And the version is still AOO340 as the issue has been found in that version!!
Comment 11 Armin Le Grand 2012-05-25 14:49:13 UTC
ALG: I have checked what happens, it's pretty complicated :-) Looks as if aShapeProp.getProperty( xDocModel, PROP_Model ) (in oox/source/drawingml/shape.cxx) does not get a chart model. Digging deeper...
Comment 12 Armin Le Grand 2012-05-25 15:47:15 UTC
ALG: Reason is from unoshap4.cxx:470 mac calls SvxUnoTextRangeBase::getPropertyValue, while the win version calls SvxShape::getPropertyValue which is correct. Why....?
Comment 13 Armin Le Grand 2012-05-25 15:52:16 UTC
ALG: SvxOle2Shape is derived from SvxShapeText, that is derived from two classes, SvxShape and SvxUnoTextBase. Mac calls getPropertyValue at the 2nd while Win uses the first. Looks like a compiler decision problem...
Comment 14 Armin Le Grand 2012-05-25 15:57:42 UTC
ALG: SvxShape and SvxUnoTextBaseRange (from which SvxUnoTextBase is derived) both have a virtual getPropertyValue. Thus, this method gets double derived to SvxOle2Shape. The mac and win compiler have different interpretations which one has to be called. What may be the C++ standard behaviour for this? We have to check...
Comment 15 Armin Le Grand 2012-05-25 16:37:52 UTC
ALG: To check I have changed the getPropertyValue call in unoshap4.cxx:470 to explicitely calling the SvxShape implementation. This did not work, I also had to do this with the setPropertyValue call in line 501. With both adapted it works on the mac, the chart gets displayed.
It seems as if the standard to call the SvxShape implementation by default has changed on the mac, probably by using a newer xcode compiler than with the 3.4beta version. Thus, one solution would be to compile with the compiler version used at that time.
This is no good solution, though. Explicit calls are also not, it will just fix this single symptom but not the changed calling order of multiple inherited virtual functions on the mac. It may be a known problem/change on the mac xcode compiler, I will have to investigate. Maybe there is a compiler switch available to turn the behaviour to the original one.
Still no good solution. All multiple derivated functions would have to be overloaded at the class where they lead to multiple derivation and in the implementation the correct one (which is not even clear) would have to be called. This seems to have been (and is except on the mac) the first class given in the declaration (here this is class SVX_DLLPUBLIC SvxShapeText : public SvxShape, public SvxUnoTextBase). I also need to find out if this is C++ standard and if the mac behaviour is an error.

Does someone have a simple and safe solution?
Comment 16 Marcus 2012-05-25 19:27:21 UTC
not a blocker issue
Comment 17 Armin Le Grand 2012-05-30 08:52:17 UTC
ALG: There were also the statements

    using SvxUnoTextRangeBase::setPropertyValue;
    using SvxUnoTextRangeBase::getPropertyValue;

in SvxShapeText. It looks as if the mac compiler is the first who really used this now in class-local implementations. Removing them allowed to find the places where the call was ambigous. There are just three places, one getPropertyValue and two setPropertyValue calls. All three are clearly aimed at SvxShape:: implementations due to the slot name. I changed all three and removedthe using statements. Checked on mac an windows, works as expected.

Adding patch. Also committing to trunk.
Comment 18 Armin Le Grand 2012-05-30 08:54:34 UTC
Created attachment 77805 [details]
Solves the wrong get/setPropertyValue calls in SvxShapeText (and thus in SvxOle2Shape)
Comment 19 Armin Le Grand 2012-05-30 09:08:12 UTC
ALG: Fixed in trunk, request AOO3.4.1 blocker flag.
Comment 20 jsc 2012-05-30 13:43:34 UTC
set release blocker flag to 3.4.1
Comment 21 2012-05-31 09:57:24 UTC
I wonder why on Windows and Unix SvxShape::getPropertyValue got called even though "using SvxUnoTextRangeBase::getPropertyValue" was explicitly requested. If the compilers had simply ignored the using-lines they should at least have complained about the ambiguity, what is what they do when the using-lines are removed. Doing the exact opposite and not even giving a warning is very strange and could lead to many other errors. E.g. unoshape.hxx contains a lot many more of such using-lines.
Comment 22 Terry Yang 2012-06-19 05:34:58 UTC
Verify fixed on trunk rev.1351249, the chart in sample file display well on Mac(10.7.4)
Comment 23 Armin Le Grand 2012-06-25 11:12:52 UTC
ALG: Merged change to AOO34 branch for 3.4.1 version as r1353458
Comment 24 Terry Yang 2012-07-03 02:36:36 UTC
Verify fixed on AOO34 Branch r1354891
Comment 25 Terry Yang 2012-07-03 02:36:58 UTC
Close this bug
Comment 26 jsc 2012-07-25 09:06:51 UTC
set target milestone AOO 3.4.1
Comment 27 2012-07-26 11:20:01 UTC
*** Issue 120369 has been marked as a duplicate of this issue. ***