Thanks... but that seems based on some older version of AOO41X... or am I missing something?
> On Aug 3, 2021, at 1:06 PM, Matthias Seidel <matthias.sei...@hamburg.de> > wrote: > > Hi Jim, > > Am 03.08.21 um 18:42 schrieb Jim Jagielski: >> Wow. This is weird, but also kind of makes sense since it seems so very, >> very platform and SDK sensitive. >> >> Someone remind me what the catalina branch is and how it relates to trunk >> and AOO42X, please :-) > https://github.com/apache/openoffice/tree/catalina > <https://github.com/apache/openoffice/tree/catalina> >> >> >>> On Jul 27, 2021, at 4:21 PM, Arrigo Marchiori <ard...@yahoo.it.INVALID> >>> wrote: >>> >>> Hello All, >>> >>> resurrecting an old thread. >>> >>> On Thu, May 27, 2021 at 02:19:44PM -0000, Yuri Dario wrote: >>> >>>> Hi, >>>> >>>>> i can build AOO 4.2.x without problems with gcc 6.3 which is in Debian 9 >>>>> I had problems to build it at Debian 10 with gcc 8.3. >>>> here I have a 4.2 build done under Manjaro with gcc 9.2: saving a diagram >>>> in ods format works fine, so it doesn't seems to be a compiler issue; >>>> >>>> How is XML writing done with ODS files? >>> It's... complicated ;-) >>> >>> I tried to dig deeper into this problem, as I could reproduce it with >>> the "catalina" branch on our Mac Mini. >>> >>> >>> Executive Summary (TL;DR ;-) >>> ============================ >>> A boolean setting is not recognized as a boolean. An exception is >>> thrown when accessing it. The exception is swallowed and the XML >>> files' contents are not written. >>> >>> >>> Details >>> ======= >>> Method XMLFilter::impl_Export() in file >>> main/chart2/source/model/filter/XMLFilter.cxx:599 [1] has the >>> responsibility to output the XML files that describe the chart. It >>> sets some common options (beans::XPropertySet xInfoSet), and appends >>> them to uno::Sequence aFilterProperties. This sequence, together with >>> other pieces of information, is passed to the three invocations of >>> method XMLFilter::impl_ExportStream(), that starts at line 754. >>> Each invocation should give the contents of one XML file. >>> But in fact they do nothing. >>> >>> Each invocation of method XMLFilter::impl_ExportStream() gets up to >>> line: >>> >>> 810: xExporter->setSourceDocument( m_xSourceDoc ); >>> >>> This method raises an exception, that is caught below at line 820. The >>> return code "nWarning" is never set to anything but zero, therefore >>> the method returns (line 824) having failed its task, but reporting >>> success. >>> >>> The question is: why does the above method setSourceDocument() throw >>> an exception? Let's look into it. I am not sure it is called directly >>> due to inheritance and virtual methods, but in the end it is [2] >>> SvXMLExport::setSourceDocument() in file >>> xmloff/source/core/xmlexp.cxx:676 >>> >>> The exception is thrown at a seemingly harmless line: >>> >>> 703: if (::cppu::any2bool(aAny)) >>> >>> because for some reason, that "aAny" value, returned by method >>> beans::XPropertySetInfo::getPropertyValue(), is not a bool, and >>> function any2bool() throws because it cannot decode it. >>> >>> But that property _was_ set as a bool by method >>> XMLFilter::impl_Export(), in file >>> main/chart2/source/model/filter/XMLFilter.cxx, at the beginning of >>> this explanation: >>> >>> 691: xInfoSet->setPropertyValue( sUsePrettyPrinting, uno::makeAny( >>> bUsePrettyPrinting ) ); >>> >>> References: >>> >>> 1: >>> https://github.com/apache/openoffice/blob/f1593045b154fade3a67d5f1771054eccc807e3f/main/chart2/source/model/filter/XMLFilter.cxx#L599 >>> >>> 2: >>> https://github.com/apache/openoffice/blob/f1593045b154fade3a67d5f1771054eccc807e3f/main/xmloff/source/core/xmlexp.cxx#L676 >>> >>> >>> Questions and comments >>> ====================== >>> Why does ::cppu::any2bool(aAny) not recognize a value constructed as >>> uno::makeAny( bUsePrettyPrinting ) ? >>> >>> Or is the beans::XPropertySet the culprit? >>> >>> Both CXX files pointed above have not been touched for at least 8 >>> years. Why are they failing now? And why are they failing on a >>> seemingly trivial issue like a boolean property? >>> >>> Maybe AOO42X introduced some changes in the overall management of >>> properties, "Any" objects and the like, that could have more or less >>> inadvertently solved this issue? Has anyone reproduced the problem >>> with AOO42X or trunk? >>> >>> I would tend to blame the overall system because of the loads of >>> warnings that are emitted by clang 12 when it compiles AOO41X. >>> >>> I don't know if it's worth the effort to further look into this, or >>> instead, just leave AOO41X working with older compilers and move >>> forward with AOO42X. >>> >>> Comments, questions, criticism are welcome! >>> >>> Best regards, >>> -- >>> Arrigo >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> <mailto:dev-unsubscr...@openoffice.apache.org> >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> <mailto:dev-h...@openoffice.apache.org>
