Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | OOo fails to import scrollbar | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Calc | Reporter: | aguelzow <aguelzow> | ||||||||
Component: | open-import | Assignee: | AOO issues mailing list <issues> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||
Severity: | Trivial | ||||||||||
Priority: | P3 | CC: | elish, hanya.runo, issues, kschenk, rbircher | ||||||||
Version: | OOO320m12 | Keywords: | needmoreinfo | ||||||||
Target Milestone: | 4.2.0 | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux, all | ||||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||
Developer Difficulty: | --- | ||||||||||
Attachments: |
|
Description
aguelzow
2010-09-08 16:00:22 UTC
Created attachment 71617 [details]
sample spreadsheet file
Result for control1.ods This file is NOT valid Result details: upload:///control1.ods:Fatal:The empty file '/space/cluster/tomcat01/temp/ODF63764/theFile.tmp' is no ODF package! please explain what you mean with scrollbar When I pass this file through the validator at http://tools.odftoolkit.org/odfvalidator/ it tells me that it is valid. The "result" you quote does not make sense. Which "empty file" is it referring to? What I mean with "scrollbar"? I will be attaching a picture of the file as expected. Created attachment 71809 [details]
screen shot
How was the scroll bar created? It can be created by one of form components. The attached file was generated by <meta:generator>gnumeric/1.10.11</meta:generator>. And it contains: <form:value-range xml:id="CTRL0000" form:id="CTRL0000" form:orientation="vertical" form:value="47.3684210526316" form:min-value="0" form:max-value="100" form:step-size="1" form:page-step-size="10" gnm:linked-cell="Sheet1.$A$1"/> The following is generated by AOO400m3(Build:9702) - Rev. 1499775 <form:value-range form:name="Scrollbar 1" form:control-implementation="ooo:com.sun.star.form.component.ScrollBar" xml:id="control1" form:id="control1" form:orientation="vertical" form:value="0" form:linked-cell="Sheet1.A1" form:delay-for-repeat="PT0.50S" form:min-value="0" form:max-value="100"> The differences are form:control-implementation and form:name attributes. In xmloff::OElementImport::StartElement method, if no control-implementation specified, its default name is tried to detect by calling determineDefaultServiceName method. But the result of the method does not stored in m_sServiceName instance variable. In determineDefaultServiceName method, the following element should be added: case OControlElement::VALUERANGE: pServiceName = "com.sun.star.form.component.ScrollBar"; break; VALUERANGE is defined in controlelement.hxx file but not shown in the detection method. After the above change, I got the crash in implGetDefaultName method called from EndElement method. This method is called because there is no form:name attribute is not specified. Why crashed, because m_xParentContainer member does not contain valid reference. m_xParentContainer.is() returns 0 in implGetDefaultName method at that time. Scroll bar by Form Controls is created, saved and reopened OK. Rev. 1499427 Win 7 Its parent form element does not contain any attributes: <form:form>... As comparison, here is generated by AOO: <form:form form:name="Form" form:apply-filter="true" form:command-type="table" form:control-implementation="ooo:com.sun.star.form.component.Form" office:target-frame="" xlink:href="" xlink:type="simple"> @Edwin: this bug report is not about whether AAO can read scrollbars it has created itself but whether it can read scrollbars contain in a valid ODF 1.2 file. @hanya: non of the attributes in the form:form element are required by the ODF 1.2 standard. Are you saying that there are attributes not are logically required for a scrollbar to be imported? f that is the case please file an appropriate comment with one of the OASIS ODF and OASIS OIC committees. Thank you and sorry. Since exact steps to reproduce were not provided, I had to use my imagination. @aguelzow These attributes are not required by ODF specification it seems. I think the problem is there in the filter implementation of the office. form:form element is imported by xmloff::OFormImport class which inherits OContainerImport< OElementImport >. The mechanism to import form:form element is the same with the one for form:value-range and others. OElementImport::determineDefaultServiceName method returns empty string for form:form importing. So if form:form element does not have control-implementation attribute, the form container is failed to be created. xmloff::OFormImport::determineDefaultServiceName should return default service name for the form component. Created attachment 81008 [details] Proposed patch to be determined without control-implementation attribute for value-range The result of type detection of the form control should be put into m_sServiceName instance variable. (So, this problem is happen on other kind of controls also?) To avoid the problem written in Comment 6, the empty parent form element passed when form:form element does not specify form:control-implementation attribute, OFormImport::determineDefaultServiceName returns default name of the form component. As side note: If form:control-implementation contains unknown name for AOO, the control can not be created. As described in 19.258 form:control-implementation of ODF 1.2 specification: >If the consumer supports the form element this attribute is used with, > but does not support the specific concrete rendition or implementation, > the consumer shall ignore the form:control-implementation attribute and > use its own rendition of the form element. Some fall back should be provided for unknown name. Confirmed per comment 11. "hanya" committed SVN revision 1656169 into trunk: #i114416# use default service name for scroll bar if failed to detect the con... Fixed on trunk. |