Apache OpenOffice (AOO) Bugzilla – Issue 119337
xlsx import with chart is not displayed
Last modified: 2012-07-26 11:20: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.
Created attachment 77532 [details] PNG of what is shown in OpenOffice vs Excel
I can't reproduce this issue againt Windows XP platform
Which build you are using? I can't reproduce it on Mac platform as well.
OpenOffice.org 3.4.0 AOO340m1(Build:9590) - Rev. 1327774 2012-04-19 03:33:29
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.
Tried different versions: It is OK on OOo 3.3 and 3.4 beta. It is broken on AOO 3.4.
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
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.
Improve the priority to P1 and move this defect to AOO35 as AOO 350 candidate
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!!
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...
ALG: Reason is from unoshap4.cxx:470 mac calls SvxUnoTextRangeBase::getPropertyValue, while the win version calls SvxShape::getPropertyValue which is correct. Why....?
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...
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...
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?
not a blocker issue
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.
Created attachment 77805 [details] Solves the wrong get/setPropertyValue calls in SvxShapeText (and thus in SvxOle2Shape)
ALG: Fixed in trunk, request AOO3.4.1 blocker flag.
set release blocker flag to 3.4.1
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.
Verify fixed on trunk rev.1351249, the chart in sample file display well on Mac(10.7.4)
ALG: Merged change to AOO34 branch for 3.4.1 version as r1353458
Verify fixed on AOO34 Branch r1354891
Close this bug
set target milestone AOO 3.4.1
*** Issue 120369 has been marked as a duplicate of this issue. ***