Apache OpenOffice (AOO) Bugzilla – Issue 78685
RPT: text field content vanishs when re-loading a generated report
Last modified: 2008-03-15 19:22:07 UTC
- open the attached database document - double-click the contained report to generate a text document - "File/Save As..." the text document to an arbitrary location (imagine you want to store it as a snapshot, for later use) - close the text document - "File/Open..." the text document, again => The text values in the first two columns have all been changed to "0" That's data loss, effectively. Also, it makes reports pretty unusable: It affects all text content, and happens as soon as you save/reload a report text document.
This is a new implementation in CWS oj14. Adding keyword "new_implementation".
Created attachment 46084 [details] document to reproduce the bug case
Created attachment 46085 [details] text document generated from the report in the bug doc
the attached text document is what is produced when executing the report. If you examine the content.xml, you will find that the cells which are affected have a table-style "ce4" resp. "ce5" (first and second column) associated with them. Examining those styles shows you they both have a data-style "N0". N0, finally, is the "Standard" format from the "Numeric" formats group. That is, the bug happens since there is a numeric style associated with the cells, and the "office:string-value" attribute of the cells (which describes the string content) is formatted according to this style - which results in a 0.
Created attachment 46087 [details] report text document after it has been saved by Writer
The second attached text document is what Writer creates when you safe the first document. Looking at the content.xml, now the table cells have attributes office:value-type="float" and office:value="0" The cell itself still contains a text (<text:p>MA</text:p>), but since the fix for i77039, the value attributes at the cell have a higher priority than the text paragraph, thus the latter is lost when reloading.
targeting to 2.3, in agreement with MSC. That's a showstopper for the integration of CWS oj14.
I checked in a preliminary fix, which at least makes this more unlikely to happen. As outline above, the problem is the inconsistency in attributes: The cells are exported with a string value, but a number format. For now, whenever you create new controls in the report designer, or change the field which a control is bound to, the designer will check whether the control has the default numeric format, and if so, adjust it to the default format which matches the bound field type. For instance, when you drag'n'drop a date column from the Field List Window to the designer, then the created control will automatically have the default date format for your system locale. Similar, when you drop a text column, the control will have a text format. This does not fix the original problem, but it makes it harder to encounter it. Due to this, I lower the prio. What's left is that Writer needs to evaluate whether conflicting attributes - a string value with a numeric formatting - should be evaluated differently. Also, it's strange that when storing the document, a office:value attribute appears at the cell, and a office:value-type="float". Where did Writer have this information from?
FIxed in CWS rpt23fix01 xmltbli.hxx xmltbli.cxx
Please verify. Thanks.
verified in CWS rpt23fix01 find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Frpt23fix01
Tested w/OOo 2.4 m_11, Kubuntu 7.1 64bit, SRB 1.0.2 FAILED - I will test again with RC5 under Linux 32 bit and XP later and if it fails there will reopen.
Tested w/OOo 2.4 RC5, Win XP, SRB 1.0.2 Running the report in the bug doc under the newer version does not clear the error, it still happens. Touching the file so that you can save the old report under the new version of OOo and SRB did not clear the error either. Creating new reports using 2.4 and SRB 1.0.2 does work properly however - so... Closing NOTE - I could not actually reproduce the report as contained in the bug doc, however, and the reason for that will be logged as a new Issue.