From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
After upgrade to 1.1.3-2.5-fc4 using yum, the Fill Series feature in
Calc does not work with formulas. I routinely continue a column with
a formula (running total column in checkbook, for example) by
highlighting one or two cells in the formula column and then dragging
the box down into blank cells (or across if continuing rows).
The default behavior used to continue the formula into the new cells,
or if the original cells had an obvious series, it would continue the
Behavior after upgrading to 1.1.3-2.5-fc3 is that it will open a Fill
Series dialog. However, this dialog either results in a "invalid
value" error or replaces the formula with a value rather than
continuing the formula.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open new spreadsheet
2. Enter a few cells of data in a column (ex: A1=1, A2=2, A3=3, A4=4...)
3. Enter a formula using this data in one or two cells of the next
column ( ex: B1=A1*2, B2=A2*2 )
4. Attempt to continue the formula in col B down to rows 3 and 4 by
highlighting B1 and B2, releasing mouse button, then dragging the
little box at the lower right corner of the highlighted area down the
Actual Results: Opens Fill Series dialog box. The Fill Series dialog
box cannot be made to continue the formula. The best it will do is
suggest a series that duplicates the values themselves (in the simple
example above where it increments by 2) but will not handle formulas
Expected Results: Older versions of openoffice, other spreadsheets,
etc. will automagically continue the formula down the column as you
drag. Or, if the original highlighted cells in the column contained
an obvious series, it would continue the series automatically. It
never even opened the above dialog.
Perhaps this is related to bug #146580 about insert/paste now shifting
cells down. I discovered the paste/shift thing after Fill wouldn't
work, and insert/fill/paste behavior in general seems to have changed
with ths update.
I called this a severe bug because, along with #146580, Calc is nearly
unusable, and you can easily corrupt a complex spreadsheet if you do
this operation a few times before you realize it is broken.
In description I said "1.1.3-2.5-fc4" above. I meant -fc3. Typo --
As a temporary workaround, rather than dragging down the fill, select
the area you want to fill, including the top entry and use
Workaround works and helps a lot! Highlighting as described and using
Ctrl-D (shortcut for Edit->Fill-Down) works as well. Thanks!
It should also be noted that this applies to fields with simple
numbers in them, not just formulas. If I have fields with "1" "2" "3"
"4" "5" in them and I drag that series into the next row/column I also
get the error reported above.
This has really cut down the usability of OOCalc.
Just want to confirm that this bug is still around in version:
FC3 / KDE
*** Bug 147252 has been marked as a duplicate of this bug. ***
1. put value 1 in A1
2. drag lower right corner down
1. "Insert" tooltip while dragging
2. "Fill Series" dialog opens after releasing mouse
1. Automatic fill of selected area with (1, 2, 3, 4, ...) sequence
2. Automatic fill with unchanged data (1, 1, 1, 1, ...) if holding Ctrl
Bug sitll exist in openoffice.org-1.1.3-6.5.0.fc3
This will be fixed in the next release.
This is also the case in Enterpries WS 4 with
Should a duplicate bug be opened for Enterprise or will this thread be
passed along to the correct people?
I just updated to 1.1.3-9.5.0.fc3 but as I can still reproduce the bug.
I confirm Comment #12.
This bug ISN'T fixed in 1.1.3-9.5.0.fc3.
This is a SERIOUS BUG, and it's been around for months! Is it really
that hard to solve? or is it just not getting the attention it deserves?
Hmmm... I disagree... sortof. I just updated to 1.1.3-9.5.0.fc3 and
when I try to drag to fill, I still get the Fill Series dialog box.
Annoyingly, none of the radio buttons, including "default" is
selected, so I have to make some choices. From what I can tell:
Choosing "linear" works for filling linear integers, but will not work
Choosing "default" will work for fomulas, but will not work for
integers (or at least it doesn't do what the feature used to do by
DEFAULT, which is detect the existing pattern and extend it).
So, I suppose the problem is "fixed" in that you can make it fill
formulas, but it's still VERY poor. This feature used to be a quick
and easy way to fill series down the sheet, and it knew what I wanted
automatically without having to ask me. Now it's a complete hassle
that has the potential to corrupt existing data in the sheet if the
wrong settings are chosen in the dialog box. Why was it changed? I
can't see that the new way adds anything. And if it has to pop up a
dialog box, would it be so hard to have "default" actually be selected
by DEFAULT, and have default work correctly for integers, etc.?
I can confirm that upgrading to openoffice.org-1.1.3-9.5.0.fc3 doesnÂ´t fix it.
It also looks like to me that Bug 147257 is a duplicate of this bug.
Since this bug has serverity high and 147257 normal mark 147257 as dup.
I confirm that 1.1.3-9.5.0.fc3 fixes bug 147257 which I reported, but doesn't
fix this one (but 2.0beta does).
Jacques: are you saying that 2.0beta from upstream fixes the bug, or that the
1.9.83 build in Rawhide fixes the problem?
Sorry: Idon't understand what "from upstream" means. I downloaded
OOo_2.0beta_LinuxIntel_install.tar.gz which contains openofficeorg*1.9.79-1 rpms.
It is also fixed in 1.9.84-1 found in ftp://ftp.openoffice.org/developer/680_m84.
(1.9.79-1 was found in ftp://ftp.openoffice.org/stable/2.0beta). Unfortunately
both aren't fully localized and I am a kind of impatient :-)
But 1.9.84 database doesn't work, as it seems (of course this has nothing to do
with this bug).
That's what we mean as upstream, i.e. from www.openoffice.org and not our
rawhide 1.9.83 or 1.9.84 rpms from download.fedora.redhat.com or its mirrors.
Now comment #14 is the current status of this on the versions of OOo available
from us, and is the intended behaviour. So the fill series functionality is
available from the dialog once you select the type of fill you want to do.
Unfortunately that's the way its going to stay. These changes address
intellectual property concerns that may cover the removed feature.
I beg your pardon. I don't think I understood your message (Comment #21) right -
can you explain it a little better?
Do you mean that the fill series in the *redhat* version of OOo Calc is behaving
weird because of *proposital* changes made by redhat? So it is not working as it
should *on purpose*??? How can "intelectual property concerns" justify that?
Caolan: I don't understand: there isn't any dialog box with
So, comment #14 is gonna be it, huh? That's bummer, because (as I said in
comment #14) the current behavior, intended or not, really cuts down on the
usefullness of this feature. Could someone please elaborate on the IP concerns?
Also, though I don't love the dialog box, if it has to be there, is there any
reason that the "default" radio button can't be selected by default when the box
opens? And, is there a reason that "default" can't do the things that the
feature used to do by default (so that it will give you what you want most of
the time, with formulas and linear series of integers, etc.)? Or, have the
dialog open with the most likely choice of radio button and values already
selected/filled in. ("default" for formulas or whatever, "linear" with start
and increment values filled in for an obvious series of integers, etc.).
Certainly this is possible, and the code to detect what the user probably wants
already exists, because that's what used to happen pre-dialog-box.
One more thing... Though I haven't tried them, here people are saying that
upstream versions (1.9.79-1, 1.9.84-1) from openoffice.org are fixed, do not
show a dialog box, etc. Are these versions newer or older than what went into
1.1.3-9.5.0.fc3? So who has the IP concern, here? RedHat? Sun? OO? Who?
Upstream is unaffected. Red Hat reviews and scrubs its code for intellectual
property issues. Our approach has always been conservative, i.e., if there is any
question, resolve the issue or remove the code. Red Hat recently implemented a
number of changes in its distribution of OpenOffice to address such issues.
These changes should not be construed as implying any immediate intellectual
property problem; rather, they have been implemented to assure that no such
immeidate problems arise. While implementing these changes in our own
OpenOffice, we have also made them available to the OpenOffice project.
Clicking on the bottom *left* corner wouldn't do it? :-)
(In reply to comment #26)
I can understand redhat not wanting to deal with IP issues, and I respect that.
However, that just explain how deliberately breaking an **open source** code can
protect redhat from anything other than satisfied customers! OO.o is already
open source so redistributing it as it is cannot be a IP violation. (or can it?
(Or is there more to it than what you mentioned in your comment? care to
elaborate a little further on the specifics of this issue?)
This is not acceptable: the way the program works does not match its
documentation (see chapter "Auto Filling Cells"), so this is a bug by
definition. Please reopen, and at the very least change the documentation
accordingly. I also agree strongly with comment #24 that "Default" should be
selected by default (otherwise, the name does not make any sense, and that would
be yet another bug.)
Reopened. Sorry, but I agree with comment #29. Until the default is actually
the default, this is still a bug. IP concerns or not...
You're only shooting the messenger reopening the bug. The "bug" can't be further
addressed, (by me in the forseeable future at least), for reasons outside my
Since it looks like we are somehow stuck here, my question is: Is there a
diffrent solution to this problem. Ex. Can we add a version without this bug to
fedora extras, if it is not possible to include it in the standard distr. Is
this bug included with a patch or do you guys realy remove (change) the source -
wich means do we have a possibilty to recompile the package without applying
this patch so that this bug is not included? If there is no patch to this - can
you at least provide one - so that every user can make its one choice to inlcude
the bug or not. Maybe some of this has already been done - is somebody aware of
a repository wich contains the rpms without the bug?
I am not trying to start a flame here by using the term bug all the time. For me
it is a bug because it bugs me (and others) - and since this has been changed,
serveral things dont match anymore. If there would be a good explenation what
exactly this IP concerns are this would be a lot easier - anyhow - I really dont
care if we find a solution here - if I find one some where else. I also use
other rpms from other repos - if this means I will have to use OO-rpms from
another source - it is ok for me.
Bug 153084 filed for documentation update.
Sorry, Caolan... wasn't trying to shoot anybody (messenger or otherwise). Nor
do I mean to complain about software that I get essentially for free.
Understanding that it's out of your control, I agree with comment #32 about
finding a solution outside of the official FC releases.
That said, is there a clean way for those of us who want to "risk" the IP issue
to use OO-rpms from another source that will be keeping this feature the way we
liked it, or will the upstream code be converting to dialog-box version of this
feature, too? I guess we never really got straight who had the IP concern in
the first place. If it's Redhat, then perhaps OO will be keeping the "old"
version of the fill series feature, and Redhat will continue to patch each
upstream release to provide the -FC release. Please elaborate on how this will
work going forward.
If indeed the upstream source will continue to work the "old" way, what's the
cleanest way to have yum use another repo for OO? (I use rpms from other repos,
so I know how to do that, but if I add a new repo that provides OO, how do I get
yum to differentiate when both repos offer the same package? I'm thinking that
the name of the package (i.e. a package that doesn't have -FC3 in the name) will
be how it knows, but please correct me if that's not right.
Thanks for your efforts on this. We really do appreciate your work, even if we
do complain from time to time...
mgm: all we can say is the following. We can't elaborate any more on the issue
other than what is below:
Red Hat reviews and scrubs its code for intellectual property issues. Our
approach has always been conservative, i.e., if there is any question, resolve
the issue or remove the code. Red Hat recently implemented a number of changes
in its distribution of OpenOffice to address such issues. These changes should
not be construed as implying any immediate intellectual property problem;
rather, they have been implemented to assure that no such immeidate problems
arise. While implementing these changes in our own distribution of OpenOffice,
we have also made them available to the OpenOffice project.
How upstream chooses to use the changes, if at all, is up to them. Anyone is
free to roll their own RPM packages from whatever source, and create a yum repo
for them. Dag does it, ATrpms does it, etc. As long as you follow the license
that each package is distributed under, you are free to distribute your own
versions to anybody you wish. Yum is fairly well understood and there are pages
around that tell you how to create a repo. Its quite easy.
Sorry if I disturb anyone. But there is no bug with
openoffice.org-1.1.2-11.5.fc3, always availilable on some mirrors, (e.g.
quicknet.nl), nor with openofficeorg-1.9.79-1.
For anyone interested...
This nug (and for me it still a bug!) does *not* appear in the 1.1.4 version of
OpenOffice available from kde-redhat-testing repos.
*** Bug 171764 has been marked as a duplicate of this bug. ***
*** Bug 201740 has been marked as a duplicate of this bug. ***
*** Bug 307191 has been marked as a duplicate of this bug. ***
*** Bug 748459 has been marked as a duplicate of this bug. ***
*** Bug 748452 has been marked as a duplicate of this bug. ***