[Bug 162417] PIVOTTABLE: Warning does not show range when overwriting destination range contents

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=162417

--- Comment #21 from Robert Lacroix <muxlab at hotmail.com> ---
> No global or compatibility option; definitely not.

OK, not wanting to chase moving targets is a good basis for this stance. Too
much confusion among users, not enough developers who understand this system or
the other.

I'm pretty easy-going, I could live with a per-PT option, for the sake of
backward compatibility. It's a once-per-PT click. I don't churn out new PTs
every day, I just work with the 50+ PTs I already have in that 45 sheet
workbook.

I *could* live with it as an option, but I will take the position that changing
it is the right thing to do, and not only to lessen the aggravation of
expanding PTs.

> First, Excel might change its (default) behavior (in some version or in the
> rolling 365 target).

That's an unfounded proposition since it affects computational results when PTs
are refreshed, and changing computations capriciously in Excel is an extremely
remote possibility. It's more likely for the user interface to change. There is
a deep history that will enrage a lot of monied enterprise users if a
snot-nosed kid at MS changes the way Excel's pivot tables work. You may not
realize that Excel is the grand-daddy which outlived its peers. It existed in
the late 1980s, when I first used it on a Mac SE, years before Windows made its
debut. That's a long time with a lot of users to make sure that MS got this
functionality right.

By the same token, it's unlikely that the default (proposed PT option) will
flip in LO-Calc some day in the future - there has to be a very good reason to
change it - and mere compatibility with Excel isn't it.

I argue that Excel's current way is the better way, since LO-Calc changes PT
results capriciously with new unrelated source data rows, as demonstrated in
comment 13.

If Excel ever changes the way PT's work, and LO-Calc preserves the current
Excel behaviour, then score one for LO-Calc! I'm not a proponent of
compatibility when functionality is at stake.

> Second, and more important, the same user might need one behavior for one
> workbook but the other behavior for another workbook, depending on layouts
> and use-cases. Someone might even think that this could be different in
> different worksheets of the same workbook, or even a different behavior for
> different PTs on the same workbook. And there you have it; the option (if
> implemented) is for each PT, not global.

So backward compatibility for the current user base is your paramount
consideration, and it is possible that some use case depends on it. (Thowing
down the gauntlet) I challenge anyone to produce a use case that works better
the way LO-Calc does it now, than the way Excel does it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.