Age | Commit message (Collapse) | Author | Files | Lines |
|
Drag&Drop of cell range onto an existing Chart worked with Calc A1
but not Excel A1 or R1C1 address syntax conventions.
Change-Id: I1cd1a134f284ef5b28237589c544f93cb4aca841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123197
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
It still worked by chance because if (!bValid) the string is
parsed with ScRangeList, which does deliver a result.
That will have to be adapted to the then expected UI
representation though in which case it wouldn't work.
Fallout from
commit 51d0b4037b36a4a74c9181b95edb18017542ab79
CommitDate: Sat Mar 12 00:21:29 2016 +0000
tdf#84938 Change defines to typed_flags
Change-Id: I9612b34829c12e59d4b390c6aa035aca84e87c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123194
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
sc/source/ui/unoobj/chart2uno.cxx
ScChart2DataProvider::createDataSource() calls
ScRefTokenHelper::compileRangeRepresentation() with the
CellRangeRepresentation property's string value and the document's
grammar (and also other places calling
ScRefTokenHelper::compileRangeRepresentation() in Chart context do, like
ScChart2DataProvider::detectArguments()), so let
ScChartsObj::addNewByName() generate that from the
Sequence<table::CellRangeAddress>.
Also let ScChartObj::GetData_Impl() parse a CellRangeRepresentation
value with the current address convention.
This is congruent with
offapi/com/sun/star/chart2/data/TabularDataProviderArguments.idl that
for CellRangeRepresentation says "The representation string is of a form
that may be used in the user interface. Example for OOo Calc:
"$Sheet1.$A$1:$D$7"", which is Calc A1 but agnostic about Excel A1 and
R1C1 address syntax. TabularDataProviderArguments is mentioned in
offapi/com/sun/star/chart2/data/XDataProvider.idl at createDataSource().
Change-Id: Ie89d9aa3d5bc3eda9a65932a445ee8a1b4b266f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123188
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
This is basically a revert of 6eb8634a9f62bfe486ecd2f46, which
made this Join() just the last range, probably under the assumption
that the function is always called with just one range to update,
or to avoid the possibility that Join() removes several items
from the list, breaking the next step of the loop. But DeleteArea()
may split several ranges, so we need to make sure to Join()
all of them.
Change-Id: Iea124142335ccdc8fa578344cddce8670c27573d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123135
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ia9a219f867ea00444844f6854f0b6af762d4e0af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122149
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123107
Tested-by: Jenkins
|
|
In LOK when we select the full row using keyboard shortcut
Ctrl + Shift + right arrow we need to receive complete selection
so we will avoid requesting it by chunks, slowly moving the
view to the right.
So - don't clip the selection rects to the visible area.
It is needed only for simple selections so to avoid performance
issues - use simpler algorithm without loops checking every cell size.
Change-Id: I6ab975b6c155f3dde3014a52752ffdc79a93844f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120611
Reviewed-by: Henry Castro <hcastro@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122107
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123099
Tested-by: Jenkins
|
|
Could occur if a conditional format is evaluated (for example if
row height is to be obtained) while a formula cell it references
is still running and iterations are enabled so the conditional
format's temporary formula cell is added to the iteration
recursion list but iterations are not triggered if there are no
circular references. In that case the temporary formula cell's
pointer remained in the recursion list and it's dangling instance
was accessed in the next round. Mark such formula cell as
free-flying and remove from recursion list if it was added.
Observed at
https://ask.libreoffice.org/t/lo-calc-crashes-when-calling-a-macro/68800
with the original attached file that now got replaced with another
version that doesn't have iterations enabled so wouldn't trigger
the bug (and apparently even doesn't if enabling iterations).
Change-Id: I23a023356f920b8413874cab14acdc8b25580052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123115
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I422a6d5b0151115203fd2d7c0fc5597903d3ec8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123064
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id88532da843e659d337f3529333a17a0c00c8328
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123050
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I59269ea818a98b4d5a2bf476b3aff2ca4f105a93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123025
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See [OpenDocument-v1.3-part3] section 19.690.3 <table:database-range>.
Regression after commit ed88b144ce24b9a733d4a9ab6614307c96537baa.
Also fixes relevant part of unit test first introduced in commit
6069ef7976c4455c1875afecf02c41c5731f6546, which was at that time
testing that IsSortColumns property returned false; then in commit
fc95d20500997a1a460be6f3553727299a5080eb, the correct value was
changed to true, reflecting the regression fixed here.
Change-Id: I6a12a0ad13405bc388efb7c2c3bbf31e89905620
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122955
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3ed657c5c5e6840e38e3c8505505b4b372125df0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122910
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Since all dxf records are stored in one place it is required
from color filter and conditional formatting to use continuous
numbering for dxf structures to avoid id collision.
Change-Id: I91146e34d462d812b480db137cda522f6db7ef8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122915
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
|
|
1. In XLSX filter colors are always stored in dxf as foreground
colors, so Calc should keep them, if possible. So practically
use only one color during import.
3. On export we need to distinguish type of filter, this is done
with cellColor=0 or cellColor=1 attribute of <colorFilter>.
4. Since p.1 there is no need to keep on export separate dxf
structures for fg and bg colors: we always use only foreground
color for color filters.
Co-authored-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Change-Id: Iacd352ae46bf84859dc15ee695b6dc63240afe7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122593
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Upper call to aParam.RemoveAllEntriesByField can invalidate
pEntry, making further calls to pEntry->SetQueryBy* illegal.
Anyway at this branch we are disabling color filter, so this
is not required.
Change-Id: Ia595649975b659d28056ba3f3658c306e63088f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122822
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
|
|
Change-Id: I4c0002e72703eded435bfe4985f5b0121bf8524b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122843
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
enforce it by making the constructor parameter non-default.
Change-Id: I321543e4dcf15ea0a43ad8cce91d2f8dc22df6ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122766
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ida3de565a736ad512e0fb7e1ef78545fefaba639
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122761
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Due to a typical case of copy-paste oversight LO Calc used to lose
the first page footer when exporting to ODS. With the typo fixed,
the export now works again.
Follow-up to commit 19fa853ce12136b5c14e0c5a0aa906c296b75388
"tdf#121715 XLSX: support custom first page header/footer".
Change-Id: If8f5ab4ff9a9392768789b886218d1d9c56ddbae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122455
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Commit 9bdb1d2473510067da1ac74013595b661ac37800 for
i51490 had introduced the same change for Bof2, Bof3, Bof4.
Change-Id: I478a8611874d70fad0c83700efed5ea882d5f69f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122650
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Fix regression of a series of commits that, intended for filter
queries, unconditionally round numeric values as shown under
ScTable::ValidQuery() and compareByValue() without having taken
into account that the same query and compare functions are used by
the interpreter for all functions that use query criteria,
possibly delivering completely wrong results including in
backports to 7.2.0.0
commit f6b143a57d9bd8f5d7b29febcb4e01ee1eb2ff1d
CommitDate: Wed Jul 7 17:44:46 2021 +0200
tdf#142910 sc filter: fix "greater than" or "smaller than" etc
commit 51375b48378915b6e95c1ac26b2ccf8e39880f7e
CommitDate: Tue Sep 21 11:06:35 2021 +0200
tdf#144253 tdf#144324 sc filter: use formatted values in filters
Several related and intertwined commits in filter context make
assumptions about these queries always being executed rounded, so
the only clean solution is to make that depend on the
ScQueryEntry::Item being passed. Its mbRoundForFilter value is set
to true for all items of all queries executed via ScTable::Query()
and ScTable::GetFilteredFilterEntries(). It might be not all are
necessary (or some even still harmful?) and unnecessarily
obtaining number formats and calling RoundValueAsShown() is still
a bottle neck for those, but that should be addressed and reworked
independently. The important part is calculations work as before.
Also, moved obtaining number formats for calling RoundValueAsShown()
into logic that calls them only if necessary.
Note the TODO in compareByValue() about suspicious rounding of
rItem.mfVal in filter context that is to be addressed.
Change-Id: Ieb178ad1ea15a635caeb1ba698c2f4b7ad676d57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122729
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
* Focused rectangle uses highlight color instead of font
Change-Id: I861f944b449d31183f082864e57071e401d3c451
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122602
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
This reverts commit 8010a0a32c232f06534fdd56c2227c9c00798cfd.
Reason for revert: The change introduced a regression.
Change-Id: I59446c62e8798cf7a6a11d916da0c1f393c87dea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122450
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Invisible menu items just don't cut it.
This adds SaveACopy also to "Tabbed Compact"
Change-Id: If6e2807467e8885ab494b291e98778c7626ebe54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122605
Tested-by: Jenkins
Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
|
|
Change-Id: I08bd46fe10a8fc35a9c2a87745ee3e8cb4c676d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116648
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: I651d6091db543ebc958f888598edd2cdef4df43a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122574
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4982d075f21f74b3d0db1c61a499dceb92e50c87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122575
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If398e3725b691491e51e49eadeb37a7fdaad63db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122554
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I083ea9ef7b04322d60ce29b7e1610332a4709493
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122553
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
while retaining the fix of #i83401# to recovered a broken case
Change-Id: I283c45b10aaa24004a34bfe6faee517d4a443b98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122543
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iedd8bd9c05dcce7e5c891664aea5d65ed408d87d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122537
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7c5a3f6e9d8368e780c50626ba7457999389f19f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122529
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6bdeb1dbe0aaa7ff2d1b65486ad326079da40e7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122521
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: Ia522fee21edeafa419c173606ebaac0667d264fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122492
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
popup was wrongly placed when dropdown was not in the first column
Change-Id: Id7170df233148564cba2fe2d498194b9e2b0161f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122396
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: Ibda7acf66bd8382de25fae9b4385d655be6ab409
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122490
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I81845c062783d59f1e3b9c612da938de42f2a50a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122463
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
See bts here:
- https://bugs.documentfoundation.org/attachment.cgi?id=175150
- https://bugs.documentfoundation.org/attachment.cgi?id=175151
Change-Id: I4954d989a25fb228624d9b4660f357219d160ead
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122409
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iddb0d69d2ffaafd81076cd52a8424c32fe3c4114
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122408
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2bc3eabeeb23534d985649c4191798ca9281b7e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122389
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I188716de98e6a9ea1c2b97c6341d578120a242b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122388
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
and change some commented out cases
Change-Id: Icc60b19de7d12a78e7d40e7aa94dae40dc8b60a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122378
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
if the results of formulas are values.
Followed up of 40acda4e78127fa9f513646ef210b074d40cf307
(Related: tdf#140968 avoid duplicated filter values)
Change-Id: Ib396d2b7cc08ba41b5936a53a28b5e38bf678b3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121715
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
save/restore in more places, and check in more places
before doing layout, so we dont waste time on expensive layout
Change-Id: I311f1f7f97a508da296078e936cb3704938dfdc3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121687
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
1) Replace the entire "Format > Merge Cells" submenu with the
single "Format > Merge and Center Cells" button with all the
same behaviour it has on the Formatting Bar.
2) Replace the "Split Cells" button from the context menu of
a selected merged cell with the "Merge and Center Cells" button
showing the current merge status, as it does elsewhere.
3) The "Merge Cells" checkbox in the Properties sidebar
Alignment section is unchanged.
Rationale:
The current behaviour of the "Merge and Center Cells" button on
the Formatting Bar is consistent with all other formatting buttons,
eg, "Align Left" is still "Align Left" (but shown activated) when
the text is currently already left aligned, and toggling it off
reverts the alignment to a default alignment. It behaves correctly
and intuitively IMO.
The "Merge Cells" button in the "Format > Merge Cells" submenu
should be removed as it appears to do the same as
"Merge and Center Cells", that is, when it works correctly. It
isn't helpful though as it has at least two problems: 1) it is
greyed out if a merged cell is selected, unlike
"Merge and Centre Cells"; 2) it becomes selectable when a range
of cells is selected that includes a merged cell, but won't
perform the merge.
Removing both "Merge Cells" and "Split Cells" buttons from the
Format > Merge Cells submenu leaves one entry, the
"Merge and Center Cells" button, which should then be promoted
to the top level menu.
Change-Id: I2f592211f888427d5bba384c28c8c3c7d92d8de6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122293
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Reading 'rectA.IsInside( rectB )' kind of suggests that the code
checks whether 'rectA is inside rectB', but it's actually the other
way around. Rename IsInside() -> Contains(), IsOver() -> Overlaps(),
which should make it clear which way the logic goes.
Change-Id: I9347450fe7dc34c96df6d636a4e3e660de1801ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122271
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I2aa7f9e8f8bc93f7422acfaac2337087060d36a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122328
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I77b8093efba3f3dfe96f6e3a4f4bfcc8dd89ccff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122273
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|