Issue 114416 - OOo fails to import scrollbar
Summary: OOo fails to import scrollbar
Status: RESOLVED FIXED
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: OOO320m12
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: 4.2.0
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: needmoreinfo
Depends on:
Blocks:
 
Reported: 2010-09-08 16:00 UTC by aguelzow
Modified: 2015-02-01 15:31 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
sample spreadsheet file (4.59 KB, application/vnd.oasis.opendocument.spreadsheet)
2010-09-08 16:00 UTC, aguelzow
no flags Details
screen shot (6.41 KB, image/png)
2010-09-22 14:50 UTC, aguelzow
no flags Details
Proposed patch to be determined without control-implementation attribute for value-range (2.38 KB, patch)
2013-07-05 16:39 UTC, hanya
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description aguelzow 2010-09-08 16:00:22 UTC
I will be attaching a valid odf file that contains a scrollbar that OOo fails to
import.
Comment 1 aguelzow 2010-09-08 16:00:53 UTC
Created attachment 71617 [details]
sample spreadsheet file
Comment 2 michel_limbe 2010-09-22 13:52:25 UTC
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
Comment 3 aguelzow 2010-09-22 14:31:28 UTC
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.
Comment 4 aguelzow 2010-09-22 14:50:07 UTC
Created attachment 71809 [details]
screen shot
Comment 5 Edwin Sharp 2013-07-05 12:21:58 UTC
How was the scroll bar created?
Comment 6 hanya 2013-07-05 13:19:15 UTC
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.
Comment 7 Edwin Sharp 2013-07-05 13:53:58 UTC
Scroll bar by Form Controls is created, saved and reopened OK.
Rev. 1499427 Win 7
Comment 8 hanya 2013-07-05 13:55:49 UTC
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">
Comment 9 aguelzow 2013-07-05 14:59:12 UTC
@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.
Comment 10 Edwin Sharp 2013-07-05 15:06:12 UTC
Thank you and sorry.
Since exact steps to reproduce were not provided, I had to use my imagination.
Comment 11 hanya 2013-07-05 15:30:38 UTC
@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.
Comment 12 hanya 2013-07-05 16:39:14 UTC
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.
Comment 13 Edwin Sharp 2013-12-03 08:52:01 UTC
Confirmed per comment 11.
Comment 14 SVN Robot 2015-01-31 08:10:36 UTC
"hanya" committed SVN revision 1656169 into trunk:
#i114416# use default service name for scroll bar if failed to detect the con...
Comment 15 hanya 2015-02-01 15:31:08 UTC
Fixed on trunk.