Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | wrong handling of date from Calc when copy&paste to Base as HTML | ||||||
---|---|---|---|---|---|---|---|
Product: | Base | Reporter: | Regina Henschel <rb.henschel> | ||||
Component: | code | Assignee: | marc.neumann | ||||
Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues | ||||
Version: | OOo 2.0.2 | ||||||
Target Milestone: | OOo 2.0.3 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
Regina Henschel
2006-03-05 21:06:31 UTC
Something for 'spreadsheet'? IMHO not for spreadsheet but for base. clu->fst: why base? this seems to be a calc specific setting and also fails in writer, like described in second paragraph. (i would guess: anything with the numberformatter?) When pasting HTML into Writer, the raw number is transferred and interpreted differently. But what do you mean by pasting into the database document anyway? Into a table view, or a form, or what? After you have copied it in Calc, goto the open Base-document, choose category "Tables", open menu "Edit", choose "Paste Special". You get the import dialog starting with "Copy Table". In step "Type formatting" select field type "Date" for that column. regina, do you copy the two cells in question only, or do you also have "header cells"? When copying the mere cells only, then they're used as column names, so no data is copied. When also copying "header cells", then I can't really reproduce your issue, since I get some "wrong data type" message. Hmm. I'd like to reproduce this issue, to form an opinion myself .... I'll attach a step-by-step instruction in pictures. Created attachment 35290 [details]
import table from Calc into Base
fs->oj: at least for the HTML part, this can probably be fixed: OHTMLReader::NextToken evaluates the "sdval" attribute of a table cell. Now this contains the (number-formatter-dependent) numeric value only, which cannot intepreted without having the number formatter - and its NullDate, in particular. Since we do not have this formatter, I suggest that OHTMLReader::NextToken uses another approach: the "sdnum" attribute of the table cell describes the number format of the string. We should use to to translate the cell content into a numeric value. If we then not only remember the textual representation (m_sNextToken), but the already-converted numeric representation, together with the number format, we should be on the safe side (and also spare ODatabaseExport::insertValueIntoColumn some work). Since I consider this data corruption (the pasted data is different from the original data) during collaboration of OOo applications, I target it for the next maintainance release. fs->regina: I'm adjusting the summary to reflect that this is about HTML and Base only. Sorry, but there are reasons [1] why multiple problems per issue are difficult to handle. At least the Writer/Web part is completely different from this one here (and much less severe, IMO). The Base/RTF part is probably (after I examined the source) also different, and also less severe IMO since the default format for pasting is HTML. So, if you want those other incarnations to be fixed, too, I encourage you to submit new issues. Sorry and thanks :) [1] http://qa.openoffice.org/issue_handling/basic_rules.html#one_per_issue Fixed in cws dba203c Please verify. Thanks. . . verified in cws dba203c 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%2Fdba203c Hi, this is fixed in the current master. The current master is available at http://download.openoffice.org/680/index.html I close this issue now. Bye Marc *** Issue 61949 has been marked as a duplicate of this issue. *** *** Issue 61949 has been marked as a duplicate of this issue. *** *** Issue 61949 has been marked as a duplicate of this issue. *** |