Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | problem while changing number of columns | ||
---|---|---|---|
Product: | Writer | Reporter: | Unknown <non-migrated> |
Component: | code | Assignee: | stefan.baltzer |
Status: | CLOSED FIXED | QA Contact: | issues@api <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | OOo 1.0.1 | Keywords: | oooqa |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
Unknown
2002-09-25 04:24:18 UTC
What makes you think that this is an API issue? I walked thru the steps described herein using OOo 1.0.1 on Win98. I verified that the first scenario is reproducible. But I did notice these squirrely traits existed only if I highlited the one line of text before making column changes. The issues are not reproducible if the text is not highlighted first. The column changes occurred smoothly and as one would expect them to when no text was hightlited prior to changing of the column parameters. And my system did not like me doing this exercise with the text highlited. My OOo stopped responding twice during these exercises, and it actually locked up another time. So 3 reboots of OOo were required to get thru these steps. The steps in the second scenario are slightly unclear. In step 2, "Later the columns value becomes equal to 3" was a tad ambiguous. The number of columns equalled 3 after selecting format, columns and viewing the number of columns in the column setting box, after performing step 1 with the one line of text selected. Again with this scenario, if the text was not selected, all changes to the column parameters behaved as one would expect. I did verify that all issues were reproducible in the second scenario too, but only if the line of text was selected prior to any format changes. This was an interesting little exercise. I will let someone else determine if OOo behaves how it is intended, or if there truly is a bug within. I will mark this issue as confirmed...but I am wondering if this is acceptable OOo behavior. These steps definitely stressed the program. Replicated on: Platform: PC Operating System: Windows 2000 NT 5.0 Version: 2190 WinXP, NT 5.01, Version: 2600 on a new document as well as on a saved document containing text. I only had problems when the number of columns was increased to more than 15 though. Otherwise the number did not change. The maximum value in the Format/Column dialog depends on the number of columns when the dialog is called. That's funny, we will have a look at it. Another remark to Format/Column: if you have no text selected, you change the number of columns of the page (template). If you have text selected, you'll insert a columned section. The problem seems to occur for sections only. Replicated on my windows xp, Writer643. First I create a file with Writer. Then formatted it into 20 columns. After that, I went on to “select all”, and format it into other number of columns. I found the choices I have only from 1 to 18 (columns). So I tried another test that formatting a file into 4 columns instead of 20. Then “select all” and formatted it into other number of columns. This time I can choose 1 to 94 (columns). Then I tried another test. Formatted the file into 3 columns first. Then, I can have 1 to 99 (columns) choices. AMA->OS: A problem of the dialog or of the core? . I'll take care for it. fixed in cws apps01 reopen to send to QA fixed in apps01 SBA: The 20-column thingie is fixed in CWS Apps-01. Verified. SBA->OS: The 99 Column variation still gives a loop. -> Reopened and re-targeted to OO.org 1.1 Beta2 SBA: Changed my mind. For easier task handling, I will write a new one for the 99 Columns that cause a loop. So I leave this one as fixed. SBA: The successor for the 99 column loop is issue 11760. Closing this one. |