Age | Commit message (Collapse) | Author |
|
... if local table is outer table.
Change-Id: I5996609264f4ad9efa8d76a8d0ab730bf1dded24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129540
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 8a9b870a40c41c7cae6e43452b593804fa17f831)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129550
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Despite 26072b8db7ba53f00c83197cb064229a76001989 and
12c6b1ef6a824b09778163ec83fc44bb196e65db, Linux builds using
RH devtoolset-7 gcc7 still hit occasional unit test crashes
with illegal instructions.
Backtrace is always:
> #0 __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at core/sc/source/core/tool/arraysumAVX.cxx:20
> #1 _GLOBAL__sub_I_arraysumAVX.cxx(void) () at core/sc/source/core/tool/arraysumAVX.cxx:112
>
So lets make sure initializer is run only on function entry.
Change-Id: I69f5cb725e4d72fb346166b21870612473f974b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129246
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
(cherry picked from commit d140817428cdbb519efa496f578bf6c054c94361)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129251
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I516bacdcd22ed094a0e9b6e125e941f32fe88c82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129238
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
(cherry picked from commit 6a0f00d3b9d1a74637c92ec6eff1ba5fedc82f3d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129341
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Note this *might* break other uses of the non-deterministic
automatic labels where exactly this constellation previously lead
to a column label. For which expecting a column label though makes
less sense..
Change-Id: Id85df7485f9b71620d8cbc404a981852d1567a54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129187
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 61cb699e88b3680becf78dc7b8bd514b2b7318a4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129079
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I67e59afc08bc5983d473cb9dceb4fcefedeec117
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129095
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
with the wrong setting it appears misplaced on a multi-monitor setup
Change-Id: I43faeb72f6678a653feef82e0f0deaf87c039e9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128958
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
so it can scroll and keep the text area to some finite size
no strings changes or new translations, so this is a backportable
change.
Change-Id: Ibc36812c6aa7fff8e035c06d0dad885909f057ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128933
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 36121e87b7e2a2defbfe75dfdadb2dde4fff6b4f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128948
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Additionally sprinkle some
TODO: MLFORMULA
comments on places where multi-line formulas should be supported
as well but code currently only works for one paragraph.
Change-Id: If2630a6493910984e0abb81ff2ed42ed51394681
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128787
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 8204d322379cbc054fb834911d88fb0fe3b040c6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128822
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: Ib588310410a265acdd129a8e51adf56bb5973bd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128869
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128910
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
This fixes 2 issues with VBA copy-paste:
- VBA command Range(..).Copy issue where the range wasn't selected
when copying and the copied cells were from the previous selection.
The Copy command now does the same selection as the Cut command.
- VBA PasteSpecial issue where the wrong view was used to get the
clip document.
- VBA Workbooks.Add issue where the new workbook wasn't activated
after it was created, which causes an issue when running tests, but
not when running in LO application. The Add command does now the same
as the Workbooks.Open command.
All the issues are supported by new test cases.
Change-Id: I36ec45c01f18f7f76e4f95a25a28402a6ee0e2e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128720
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 0c6ee963e1f089cb73e0c68a28af29d0f8d9e0df)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128678
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
... to tie result to 0 eliminating opposite sign small equalish
fractions.
This does not "fix" all interim values of the bug's sample document,
which repeatedly adds single values in sequence using SUM() and should
use the + operator instead to benefit from approxAdd() for each, but
maintains the better accuracy of Kahan summation in the not near equal
zero cases. And the dreaded SUM(0.1;0.2;-0.3) also works again resulting
in 0 with all permutations.
Change-Id: I67188a6abbdb98212f070166ad02319c3d477e28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128451
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 730b8aba72356bb8ba0066a5517b1224a4f1e232)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128432
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Only in Calc, Draw and Impress.
Change-Id: I944aad875fedd1dd19657c49b059e33fd6e9d3f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127984
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
(cherry picked from commit 0596ef354ee8d40976c6be044a646757240f7921)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128443
Reviewed-by: Po-Yen Huang <jeff@mail.ossii.com.tw>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
but the cursor is at pos 0
Change-Id: I7c94480bffdced23fe89d4e3ba0e729742247130
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128414
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 4bdf28b404f90236d93ce207671f755a71f28496)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128429
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Check for a multiline string in the setDataArray function. If that is
the case, set a string or edit cell. Otherwise, just set a plain string in order to prevent performance issues due to the adjustments of the row height.
Regression from b9e2c5d2a36fbd189c20448cadf4212edf02914d
Change-Id: I9216b198b878fda5da29596d25504db853acd756
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127660
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
(cherry picked from commit 2d11710df6d81c03007d136667a443e09cc70eed)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128332
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
If there is no dxf reference to color filter (for example if selected
color is not in range of available colors for current range) Excel
is not able to show color filter correctly: it is not marked as used
filter, no ability to reset, etc.
Change-Id: I65378ddd6f8f8233cda147ff9dcd28f455a58225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127745
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
(cherry picked from commit f0ad6ec2a23a36ade407db8cda36655ba2f144c1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128159
|
|
... when the handler decides to remove itself from listeners.
Change-Id: I1d5fe802f50d284bf70d747edaff0a19852c5a7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128054
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit e9dce4e8cbea04d6c6636a45f5a172e986714409)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128074
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
not those seen at the initial load of the TabPage
Change-Id: Ieba4c278a0a9b7fef3030d8462cb845c27dba9b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127959
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
when built with -ffp-contract enabled (-ffp-contract=on default on Clang 14
trunk since
<https://github.com/llvm/llvm-project/commit/f04e387055e495e3e14570087d68e93593cf2918>
"Making the code compliant to the documentation about Floating Point", cf.
19559ebbee160d1625d06feec7e6566772dad231 "Allow for a presumably more precise
result of BESSELY(80,9)"; and -ffp-contract=fast default when building with
optimizations on GCC) on both Linux (with
6cb20e0b298f41fe88984aebfe5454f936a0ae3a "Disable
CppunitTset_sc_*_functions_test for linux_aarch64 for now, too" reverted) and
macOS.
Change-Id: Ie867d999173410ec9868bd14c0ee04bbba371920
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126727
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 72b25619960cdaa829c8ea10e27d9c0b20a2c26f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127784
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Otherwise, this might fail. See 660e538ee77109bc3e7dff4491164d696e503abc
< Disable broken part of ScFiltersTest2::testTdf126116 >
Change-Id: I40534b70fc19ee163d9e6cb0c081fae40b81fdb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127774
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Previsouly a given ELSE-path was executed as the condition is never
TRUE on error, which wasn't significant unless the ELSE was an
error evaluating function like IFERROR() or ISERROR() or other
IS...() functions.
This changes behaviour of an undocumented side effect, so *might*
break existing expressions that (unwillingly?) relied on it.
Gnumeric, Excel and GoogleSheets all agree on propagating the
error value as implemented now.
Change-Id: I0905a363be7a3b02925f1c41b4e6c8d36f12df93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127515
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 1c14b9efb0677dea65ff220222fbb8d5c2aa6973)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127481
|
|
... instead of forcing Err:504
Change-Id: I7e91671ffc61bf82d9095378656b41981040f55e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127492
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 4674ff347cd2e71445503efdc0c110d094daa80b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127476
|
|
SbxValue::Clear happens to not error out on clearing string and some
other types of objects, but for the rest, it calls SbxValue::Put, and
the latter errors out if not CanWrite(). The original test implemented
in commit 24d24debef4cda7de702c4b470a3707f1aae3ea3 only checked string
return value, so happened to miss this problem.
See similar code in SbiRuntime::FindElement.
Change-Id: I7c17137cc9e7ee3133ee86a9f701559df66e53b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127248
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 822998f1dc202aba7a558767f641687aef0c1148)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127257
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
While at it, move the file from ods to fods
for better tracking in git
Change-Id: I16df221e3a7341dc7c53de6130158c3887c472a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127361
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit f4ab9cf69c3b1e9f17fc3873f160ddebd5f812fb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127370
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
When mutliple data ranges existed in one sheet, only the first one was
considered when exporting color filters.
Consider all of them, as any could hold a color filter.
Change-Id: I13ae2018057eef7ef24fc8298c814a93df24f74b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127328
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
(cherry picked from commit b85e99950dc4584160512cffec303827c02f2d15)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127259
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Apply only those that are actually specified.
Change-Id: Ib2e090fefe4dbfe3d4fca2b953bcf51d97d9ddec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126901
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
(cherry picked from commit 6b2da3ae3ea7f47dff3c807c151f88a9e1ae9964)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127167
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I53553f91eeb5bd56bbad19b80421177a84625d96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126616
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127151
|
|
Change-Id: Ief752f20aa3e7672e4ed7f6cd1809ee56a096c43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127051
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This fixes a LO 3.6-ish regression.
Things have changed a lot since then. I assume that pCell
was empty when it was hidden. The test for pCell was
removed in commit c06dbbe7594c2a0b5a5b19f8e183d9c421e6e094,
which was in the range that bibisect suggested.
Change-Id: I0af137358335a808de901111a71f5c113fabcf24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127001
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
(cherry picked from commit b58dbb862296b63f3f2395c59d30fba40fa5f59f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126975
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I76c0d57da63c1e35f80b13071793dbbb27cb218a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126655
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
(cherry picked from commit aadbac5467bb6ab768f87ed6ec003c55159d54aa)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126886
|
|
Change-Id: Ifa662a9d55fae10e3e1e3e115c9c5eb10972cbbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126899
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit ec4f8cd2172bf7b232961f31ebd22d7e13af261e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126882
|
|
For the bug doc example the #C target lead to always column 1
(A,0) being selected. Instead, the column of the current cell
cursor position should be selected as C is the short notation for
C[0] in R1C1 address syntax.
This does not "fix" the alleged bug but would yield the desired
behaviour if there was no sheet C where the intention was to jump
to.
Change-Id: Ibaed0250b9fb2cbc7f15a4b22404c48b39d41ff8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126496
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 155024040de888270bf90bdd200799cea7d73e4e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126825
|
|
E.g. SC_CONTAINS is, according to isPartialTextMatchOp(), a text-only
operation, so query it as such and not as a numeric value. This
fixes/allows e.g. substring queries on dates.
Change-Id: I6c612d9934193828b7a7eabed92f2bfeb385e5a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126767
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 0d1971a8dc1f7ce24f67abcab4d6af9cf2b7b823)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126816
|
|
In the conditional format screen, set the actual condition for an
inactive date entry instead of "Date is today" in all cases.
Change-Id: I3d3f05c35a9830a1e82d68521e80e88c99b43a90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126059
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
(cherry picked from commit dfdf33a34729de7f256ed396be93fb96b4844404)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126238
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
When typing "=a", autoformula was suggesting
ACCRINT,ACCRINTM,ACOS instead of starting with ABS.
[This has been true since these 3 suggestions started in LO 5.2.]
Prior to this patch, the very first item in the sorted list
(ABS) was placed at the end of the suggestion vector.
That is because the loop immediately increments.
Since the given initialization value is end(),
it set begin() as the starting loop value and then
immediately incremented to item 2.
Item 1 was finally evaluated last, putting ABS after ZTEST.
The backwards loop handled this properly,
so do the same thing for the forward loop.
Change-Id: I539c749ea43140a1480d74471787bc886dda671e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126723
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit b2fb1631ab5b3c1d9d09aefa0d3a81307e7ffa35)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126750
|
|
Prior to 4.3, only MRU formulas were auto-completed.
Then it changed to suggest all formulas - alphabetically
for the most part.
That 4.3 commit 5b0b7553241bb5150b12bbf7625b4b0b36970272
completely removed all reference to MRU.
But it makes sense to prefer an MRU over a strictly
alphabetical match.
This patch depends on LO 7.4 patch
"new ScTypedStrData: typically missed argument in CTOR"
Change-Id: Id5d860d1401693f43833719977d1c1e4c386385c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126499
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit b93a6964e0466c1b67d2c233040357a8f6c75214)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126749
|
|
Introduced in f773e7aa8c96e070085ece95889f02590ed65f89
< Resolves tdf#144227 - Default command to switch UI >
Change-Id: I1975d6d61a2fd225e87dffe65708a1f5e531f106
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126735
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit 29bbed22e404700f9538e244df6e02681da1fc1b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126747
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Fix description:
Avoid storing a reference to the object-contact
(sdr::contact::ObjectContact) of the page-window (SdrPageWindow) related
to ScDrawView in the "proxy" object-contact. In the current setup there
is no way to invalidate the proxy object when the original
object-contact and its page-window are destroyed (in this case it seems
during a sheet-switch). Instead query the real object contact just in
time when the grid offsets are requested from the proxy object-contact.
Performance:
Behaviour of offset computation is not affected. It is still cached in
the "real" object contact and it is only computed after it gets
invalidated (because of change in zoom)
Crasher reproduction(LOK):
1. Create a spreadsheet with two sheets - one with a table of texts and
shapes and other may be empty.
2. In first sheet select a single row(via header) and press Ctrl+X.
3. Go to the empty sheet, and paste (Ctrl+V) and immediately save using
Ctrl+S.
---Relevant part of backtrace-----------------
<signal handler called>
0x00007ff96781cc70 in main_arena () from /lib64/libc.so.6
0x00007ff964f2f47b in sdr::contact::ViewObjectContact::getGridOffset (this=0x6f01f20) at /opt/libreoffice/co-2021/svx/source/sdr/contact/viewobjectcontact.cxx:456
0x00007ff95cffac5a in (anonymous namespace)::ScLOKProxyObjectContact::calculateGridOffsetForViewOjectContact (this=0x6fb00a0, rTarget=..., rClient=...) at /opt/libreoffice/co-2021/sc/source/ui/view/gridwin4.cxx:1315
0x00007ff964f2f493 in sdr::contact::ViewObjectContact::getGridOffset (this=this@entry=0x5e0c5e0) at /opt/libreoffice/co-2021/svx/source/sdr/contact/viewobjectcontact.cxx:459
0x00007ff964f30732 in sdr::contact::ViewObjectContact::getPrimitive2DSequence (this=0x5e0c5e0, rDisplayInfo=...) at /opt/libreoffice/co-2021/svx/source/sdr/contact/viewobjectcontact.cxx:364
0x00007ff964f30a82 in sdr::contact::ViewObjectContact::getObjectRange (this=0x5e0c5e0) at /opt/libreoffice/co-2021/svx/source/sdr/contact/viewobjectcontact.cxx:198
0x00007ff964f30d00 in sdr::contact::ViewObjectContact::ActionChanged (this=0x5e0c5e0) at /opt/libreoffice/co-2021/svx/source/sdr/contact/viewobjectcontact.cxx:220
0x00007ff964f20294 in sdr::contact::ViewContact::ActionChildInserted (this=0x5dd83a0, rChild=...) at /opt/libreoffice/co-2021/svx/source/sdr/contact/viewcontact.cxx:180
0x00007ff96506628a in SdrObjList::impChildInserted (rChild=...) at /opt/libreoffice/co-2021/svx/source/svdraw/svdpage.cxx:288
0x00007ff95c808bcd in ScDocument::CreateAllNoteCaptions (this=<optimized out>) at /opt/libreoffice/co-2021/sc/source/core/data/document.cxx:6614
...
0x00007ff95cbedcc5 in ScXMLImportWrapper::Export (this=this@entry=0x7fff5432f110, bStylesOnly=bStylesOnly@entry=false) at /opt/libreoffice/co-2021/sc/source/filter/xml/xmlwrap.cxx:730
0x00007ff95ccfd896 in ScDocShell::SaveXML (this=0x5c4c330, pSaveMedium=<optimized out>, xStor=...) at /opt/libreoffice/co-2021/sc/source/ui/docshell/docsh.cxx:556
0x00007ff95cd009c7 in ScDocShell::SaveAs (this=0x5c4c330, rMedium=...) at /opt/libreoffice/co-2021/sc/source/ui/docshell/docsh.cxx:1801
...
0x00007ff95d081af4 in ScTabViewShell::ExecuteSave (this=0x5e9b100, rReq=...) at /opt/libreoffice/co-2021/sc/source/ui/inc/viewdata.hxx:354
-----------------------------------------
Change-Id: I00eac440546624bc448dcd30499957dea7c1de87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126471
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
(cherry picked from commit ff175d858e897964d81cf3b7edaa6ccde32e098b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126519
|
|
This is a partial revert of LO 6.1
commit 009d2756b1678477ec23d5647bd5004c4bff3a62.
It is one thing to change code that you don't really
know why it is setup that way, but it is another thing
to ignore the resulting regression reports for 3 years.
Not impressed.
It look me only 1 hour to work through this,
and this is completely outside of my normal
line of programming.
Change-Id: I8671677f38cc1332c6c5a76847801e2680097048
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126500
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
Reviewed-by: Justin Luth <jluth@mail.com>
(cherry picked from commit a99aea61c3199dc8188d4d873a10201082dff2e2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126686
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Since LO 6.3, only 64 columns are created by default,
where previously it was a fixed 1024.
A common user practice is to hide all columns not used,
but this collapsed property was lost because
only part of the columns were actually created and thus exported.
In this example, import specifies 1017 hidden columns (H-AMJ),
but since only 64 columns are created, export only specified 57.
So ensure that on import, any column with defined properties
is created - even if they don't contain any content.
Change-Id: If928880baf5585613715a1f4361a9059584d1ad2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126540
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
(cherry picked from commit 297ab561c6754f89326a1e8ce1751233669578d7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126668
|
|
The functions accept empty second arguments, but the function
wizard and hints stated that it was required.
Change-Id: I74fcfcc31492ed776085d1bc6ee6a9ff22a87818
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126620
Tested-by: Eike Rathke <erack@redhat.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 885465bc0ae6029d8adad57015fb0ff6c26a6ba6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126594
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Pretty much any attempted use of eType was completely wrong and lost.
Regression from
commit f6b143a57d9bd8f5d7b29febcb4e01ee1eb2ff1d
CommitDate: Wed Jul 7 17:44:46 2021 +0200
tdf#142910 sc filter: fix "greater than" or "smaller than" etc
Most calls to this are missing the "rounded number" argument,
so the enumator is actually accepted as the double fRVal,
and the StringValue eType was left as the default value (Standard),
instead of the intended enumerator.
0.0 looks too much like 0, 0 to even notice in
casual code reading.
This had rendered the type mostly irrelevant.
Change-Id: If4fa69d4b3077981244a2c3a785f80b77f9f9501
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126453
Tested-by: Eike Rathke <erack@redhat.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit ac1ea5944a236efef75af7c85d0ffe10d374e7fa)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126592
Tested-by: Jenkins
|
|
Change-Id: I8a324d6a037c8a5c0efc0b2825657513c2f9841c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126159
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
(cherry picked from commit b9362e87a3646a6693b81fb0d40e28ce7813a251)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126441
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
introduced in 3092322bb83998397b09d3f34b6d04b5e5c1da50
The intention was to avoid the default line drawing in the original else
branches to be conditional on bMergeCover. The previous patch used
'bGrid' as a surrogate for the original 'else' case - which is wrong.
Change-Id: I7c6b49fa9c21064312273b1051ffc7f81de3fef3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126076
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
(cherry picked from commit 307c1f13821386687b8cf3c560ff2570b89ac3a9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126134
|
|
so changing cursor pos becomes hit or miss in the dropdown arrow
shown case
Change-Id: I6e08a022041667fe8368b2cb09289a598957eb87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126511
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...after 8406139062d9ffe1daed32aefe4e261c6c55d63e "process broadcasts for
adjacent cells together (tdf#119083)" during CppunitTest_sc_bugfix_test,
> sc/source/core/tool/grouparealistener.cxx:340:72: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Change-Id: Ica29fc4c204cd6fd5c52c61271ebfcc9691f7f6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126458
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 70fc728ceef4dcf45dd97dc9051ddb73ff734169)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126437
|
|
...after 8406139062d9ffe1daed32aefe4e261c6c55d63e "process broadcasts for
adjacent cells together (tdf#119083)" during e.g.
CppunitTest_sc_ucalc_copypaste,
> sc/source/core/data/documen7.cxx:143:59: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Change-Id: If848747f6b004219475b39b48c6a3de086bd1ae7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126457
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 8bc85cd8a6a9a879c143d8defacc45967a0ac99e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126436
|
|
The problem in tdf#119083 is that it sets up listening for the range
of cells used by VLOOKUP, and when adding a new column changes all
those cells, it results in repeated SfxHintId::ScDataChanged
broadcasts to the cells with the VLOOKUP formula. This commit
makes ScHint include a row count, making it possible to group
adjacent rows for SfxHintId::ScDataChanged together and send
notifications just once for the range.
Change-Id: Ib3439de58a2b1e5e8f01b037a62608e38b8e9125
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126395
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126448
|
|
It's somewhat confusing that an accessor is provided to give
a reference to internal data and then the object is modified
indirectly using the reference. It appears to be only for
performance reasons, so I thought that inlining the ctor and
ctor could help the compiler to optimize this, but apparently
it can't move this outside of the loop, so at least make it
clearer.
Change-Id: I72cf15d1446daa559ac4079b9478e53694d7d198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126394
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126447
|
|
This somewhat improves the situation, but still a lot of time is spent
repeatedly making the same cells dirty.
Change-Id: I3444ca6dac4b3a40c6ac40a0b70cf5baeefa2f09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126391
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126426
|
|
The code assumed that there would be only one ScQueryEntry.
Change-Id: Idf4cc6bdbbf1edad7d13eb9a9643bb67e199dd01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126368
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126300
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|