Apache OpenOffice (AOO) Bugzilla – Issue 7326
shrinked text in cells of a sheet unvisible when seen as a data source
Last modified: 2003-09-08 16:55:29 UTC
In the attached file the first sheet looks like the following: [A] [B] [C] [D] [1] Id Number Label Duration [2] 1 1 Main task 02:45:00 [3] 2 1.1 Subtask 1 01:00:00 [4] 3 1.2 Subtask 2 01:30:00 [5] 4 1.3 Subtask 3 00:15:00 [6] 5 2 Second task 03:00:00 Since rows 3-5 contains data of a lower level, it makes sense to shrink the cells (i don't know if "shrink" is the right term, i've got a french OOo... localization and bug reporting aren't good friends) When defining the sheet as a table of a data source and displaying its contents, the contents of all "shrinked" cells do not display.
Sorry will attach the file asap but wor the moment when i want to display http://www.openoffice.org/issues/createattachment.cgi?id=7326 i get an Internal Server Error...
Created attachment 2618 [details] here's finally schedule.sxc
Nicolas, thanks for posting. Could you please attach screenshots of the problem you are describing? I don't understand what you mean by shrinking cells. Could you also list the version of Linux you are using?
Created attachment 2629 [details] the screenshot
OK, I attached a screenshot which could make things clear. By "shrinking" cells, i mean "more indenting" their contents... the appropriate icon looks like this: --+---- ====== -> === --+---- In the screenshot you can see that the 'Number' of the table dosn'd display the values from 'indented' cells. Right, 'indented' should be more appropriate. The problem both occured on a Debian Woody box and a Mdk 8.2 box, with either OOo 1.0 or 1.0.1
Nicolas, thanks for the additional comments and the screenshot. Okay, I now understand what you are talking about and I have a few comments. 1. The reason why the indented rows in the Numbers column do not display is because they are formatted as text and not numbers. Since this is a database source, my guess is that OO uses the second row to determine the type of the column. If you change rows 3 to 5 as numbers, the rows will show up in the Data Sources view. 2. As for the indenting, it doesn't make sense that font formatting would show up in a database source. A database usually only stores type and data information. There is no concept of "font formatting" inside a database table.
Thanks for dealing with this issue ! OK, now it is clear to me that the problem has nothing to do with indentation, but it still remains. > 1. The reason why the indented rows in the Numbers column do > not display is because they are formatted as text and not > numbers. > > Since this is a database source, my guess is that OO uses the > second row to determine the type of the column. > > If you change rows 3 to 5 as numbers, the rows will show > up in the Data Sources view. Why should i do this, if it makes sense to me to deal with serial numbers, and not only pure numbers ? What if i want to type '1;1.A;1.B' instead of '1;1.1;1.2' in my initial sheet ? I created another file, issues.sxc. The deal is to list the number uf solved bugs for each OOo build. Of course, the numbers aren't real. Buthere you see that i *must* cope with the fact that OOo build numbers (641, 641c, etc.) contain letters, they're not pure integers... welcome in real life ;-) I'm also about to attach two related screenshots, the first one shows a sheet with indented cells, the second shows a sheet without indented cells. The problem remains without indentation, so i guess you should rename this defect. Cheers, Nicolas
Created attachment 2654 [details] issues.sxc
Created attachment 2655 [details] solved_issues.png
Created attachment 2656 [details] solved_issues_2.png
changing component, QA contact, and owner - this is a spreadsheet issue, though the spreadsheet at this point uses some data access core functionality.
Nicolas, thanks for the additional information. I've taken a look at the new attachment, and I can make the new spreadsheet work as a data source. Format the "Build" column as text. I think we might have found another issue though. I have to reenter in the text in A2 and A7 before the formatting changes are saved. All the data is listed properly in the Data Source view.
Just addition notes. While testing the file issues.sxc, Calc tended to crash a lot. Sometimes it would crash during an application exit and other times Calc would just silently crash. The problem is, I cannot reproduce the crash on a consistent basis. I can upload Dr. Watson logs if the developers feel it might be useful.
Indenting doesn't have anything to do with it. The data type for each column is determined from the first non-empty cell in that column. In your example, column B is recognized as numeric, so text cells like "1.1" don't have a value. There is no foolproof way to know if a column was intended by the user to be text or numeric. The "first non-empty cell" method is the best we can do.
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details. First step in IssueZilla is unfortunately to set them to verified.
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.