ScSortInfo is rather small POD object, so rather than using the heap,
and doing lots of pointer chasing, just allocate them in nice big cache-
friendly arrays.
Change-Id: Ice7b6afc73c7f6e2af51855d38184640ef440e46
Reviewed-on: https://gerrit.libreoffice.org/51914
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
regression from
commit 8d54796bf1 (patch)
enhance pass-by-ref plugin to detect large arguments
which converted this peice of code into an O(n^2) loop
Change-Id: I0473a084518c0d10411615e1b3901b9b90144bc9
Reviewed-on: https://gerrit.libreoffice.org/51956
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
this patch only tweaks a few things around the edges. The bulk of the
cost is down in the chart2 module where it creates ticks and labels.
Change-Id: If73a16d2f0a7511f07eff379a9b5c1b38ef96786
Reviewed-on: https://gerrit.libreoffice.org/51931
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... as used in LOOKUP and VLOOKUP.
This was disabled as a fallout from
commit bad266fa06
CommitDate: Mon Feb 22 21:30:28 2016 +0100
ScQueryEntry::GetSearchTextPtr() with SearchType, tdf#72196
that changed the !bRegExp condition (which includes numeric) to
bLiteral (which covers only text string) searches.
Change-Id: I265286ffe75bc7cd9e660ab82b0e647d82865eb9
and
coverity#1430076 Division or modulo by zero
coverity#1430078 Division or modulo by float zero
coverity#1430082 Division or modulo by float zero
coverity#1430083 Division or modulo by zero
coverity#1430085 Division or modulo by zero
coverity#1430102 Division or modulo by zero
coverity#1430103 Division or modulo by zero
Change-Id: I9d7190f95d19a755c681f1f897a8921105ef7c46
Reviewed-on: https://gerrit.libreoffice.org/51568
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
regression from
commit 6529cd54c2
don't use heap for elements in ScRangeList
The change in lcl_MoveRanges is not part of the fix, just something else
I noticed when reviewing the problematic commit
Change-Id: I958937f92a84f6e8e7bec607705c3a958d70ad3c
Reviewed-on: https://gerrit.libreoffice.org/51547
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
And if it is only an assert() where code (probably rightly)
assumed there is a value.. if there wasn't then we'll have to
handle it.
Change-Id: Icbdb4a7727ca4cf8a6372c03e02d3bffa6156b6c
Reviewed-on: https://gerrit.libreoffice.org/51374
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
MODE.SNGL is to return the first occurrence of the number that has the
most occurences in the array of numbers in case of multiple
numbers having the same amount of (maximum) occurrences.
Change-Id: If76115ddc6b84367cbcb75de611f29076a538476
Reviewed-on: https://gerrit.libreoffice.org/50593
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
no need to store small objects like this out of line.
And use std::array for ScRangePair, so we get range checking in debug
mode.
Change-Id: Ie4690edbb4c3fdc4e08206cb016b8167a399d95a
Reviewed-on: https://gerrit.libreoffice.org/51268
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
If nOverPos<i and i was last element, the next pOver=&rRange was
invalid, though not deleted because std::vector::erase() does not
reallocate.
Change-Id: I22d9302e2d45403dd47ac1947d2cf003b3a4f291
When anchor type "To cell (resize with cell)" is selected, we do now::
1. Consider aspect ratio when scaling graphic objects with cell
This only works when the image fits into one cell.
When the image is over multiple cells, we need to respect the end
anchor, so we need to keep the existing behavior (no aspect ratio considered).
2. Always scale images if anchor type is "resize with cell"
Previously it would only scale if the image is larger than the cell.
Now we always enlarge the image if the cell is enlarged, and shrink
the image if the cell is shrinked _and_ the image no longer fits
into the shrinked cell
Change-Id: Ib2a24819d0058bcebce73ea97bbf70a963d74584
Reviewed-on: https://gerrit.libreoffice.org/50451
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
... to prevent further confusion what it acually returns.
Follow-up inspection of places where used might be necessary, and
whether an IsEmpty() is used and necessary or an IsAnyEmpty() or
some such would be needed.
Change-Id: I7975a97f0d16442cf195956d148bfb7fbdf89c6a
Reviewed-on: https://gerrit.libreoffice.org/51055
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
Winfried Donkers