Apache OpenOffice (AOO) Bugzilla – Issue 7882
problem while changing number of columns
Last modified: 2013-08-07 14:43:39 UTC
Here are the steps for replication of this bug : First Scenario : 1.Open a new OpenOffice word processor document. 2.Type and select one line of sample text. 3.Select ---- Format ... Columns 4.Make the 'Columns' value equal to 20 and pres 'OK' [Here page gets divided into 20 columns] 5.3.Select ---- Format ... Columns 6.Watch 'Columns' field : 7. It shows value 18 instead of showing 20. Try increasing the value of field 'columns'.It does not exceed beyond 18 and has the new changed domain [1-18] 8.This problem does not occur if we select values less than 4 , instead of 20 in step 4. 9.Repeat steps 1 to 6 , with columns value = 4 in step4 (instead of 20) 10.After finishing these steps , the column value remains at 4 , but the maximum value we can choose now is 90 and not 99 as previously. So the domain for columns value = 4 is [1-99] 11.Similarly for columns input value more than 3 at step 4 , we get a new domain , which should not happen and remain [1-99] always. Second scenario : 1. Repeat the steps 1 to 6 from first scenario , with columns value = 99 at step 4. 2.later the columns value becomes equal to 3. 3.Scroll down that value to 1 in columns field.(Dont press 'ok') 4.Try increasing that value again by scrolling. 5.After getting to 1 , it does not get changed thereafter.we have got the variation from our first scenario while testing the columns field at upper boumdary value. Thank you.
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.