Apache OpenOffice (AOO) Bugzilla – Issue 22747
XML filter adaptors and macros
Last modified: 2004-12-08 13:30:13 UTC
Why are the document's macros not passed to com::sun::star::xml::sax::XExportFilter::XDocumentHandler? It seems to be impossible to write (in C++, at the API level) an export filter which exports the document macros (as the com::sun::star::script::XWhatever APIs don't work either).
MIB->AB: The XMLImporter and XMLExporter seervices in fact do not import and export macros at the moment. What's required to do so is an additional service that exports macros into a a flat XML file that can be used by the XMLImporter service. The same is required for the import.
-> Started
According to the roadmap of OpenOffice.org 2.0 (http://tools.openoffice.org/releases/q-concept.html) this issue has been scheduled for 3.0.
I don't think that's an OOo Later issue: #116240 of our old bugtracker database describes a problem we haven't had in OOo 1.1 with macros at events. See: tEventsToObjects testcase in http://qa.openoffice.org/source/browse/qa/qatesttool/xml/update/inc/sxw_03.inc JSI->AB: Is it possible to fix it in OOo 2.0 timeframe?
setting keyword "regression".
AB->JSI: Everything depends on priorities. I'm sure this could be done in OOo 2.0 timeframe. The question simply is if it is important enough to do it instead of other fixes. According to TBO's comment above obviously somebody decided that it is not important enough. I don't see what #116240 has to do with this besides the fact that the problem described by this tasks makes it more difficult to reproduce. And as far as I remember the scenario this task is far from beeing simple. Of course you're right that this is regression in the sense of "functionality is lost" but unfortuna- tely due to the completely new bin filter concept this is not just a small mistake somewhere but really missing functionality requiring a lot of work.
#116240 describes (in a summary) that loading events on objects (=macros) in an .sdw and saving them in an .sxw (XML) runs into data loss. We have searched for the reason and did not know that we all have agreed to loose SO5.2 macros now in OOo 2.0 - because we have no problems in OOo 1.x. And yes, "loosing functionality" is the most important criteria if there is no decision which said that we have agreed to do so.
I have changed the target after some evaluation and this is data loss. If you want to set it down to a lower target we have to escalate it,
Changing type (it's a defect) and priority (data loss=2)
.
accepted
fixed in CWS xmlbasic
reopened
TBE->JSK: Please verify in CWS xmlbasic.
checked, fixed
close