Age | Commit message (Collapse) | Author |
|
Have two releases be able to read ISOWEEKNUM first.
Change-Id: I7ea8141043d18076a65396374dec40a806c8ab6a
|
|
... instead of a temporary instance and AddToken() that just clones it
again.
Add function comment describing the difference.
Change-Id: I3f089965d394b33d7bbbb9a1c3f69dc1c4182fd2
|
|
... instead of AddToken() that just clones it again.
Change-Id: I99b02b0924d0a0c070435501f8ecd45f030e9c2c
|
|
The remaining cases when loading old and wrong ISOWEEKNUM that can't be
mapped to either new WEEKNUM or ISOWEEKNUM now are mapped to
WEEKNUM_OOO(date,mode) with calculations identical to the old and wrong
OOo WEEKNUM.
These WEEKNUM_OOO cases are still wrongly saved as ISOWEEKNUM so can be
read by 5.0 or earlier versions as the old WEEKNUM, which should be
changed for 5.3 or later.
WEEKNUM_OOO is not offered in the Function Wizard to prevent deliberate
usage.
Also reverts the interim unit test change to
sc/qa/unit/data/contentCSV/date-time-functions.csv
that was necessary to catch the error generated by ISOWEEKNUM with two
arguments.
Change-Id: I874c4c7225900f03b879f2947512ae02270cbd4f
|
|
Change-Id: Ica344a8f1351826e53c109ef49f80e4b022a0364
|
|
5.0 and earlier implemented WEEKNUM(date,mode) with mode!=1 such that
effectively an ISO 8601 week number was calculated. WEEKNUM was wrongly
saved as ISOWEEKNUM (even with two parameters though it is defined to
have only one) so that when reading it we can try to detect a literal
double argument for mode and if it is not 1 remove it to keep
ISOWEEKNUM(date) instead of calling WEEKNUM(date,mode) which wouldn't
match.
A further change to 5.0 to accept also only one parameter in
WEEKNUM(date) and for this default the mode to not 1 for ISO week will
yield forward compatibility.
Change-Id: I88de7dd809d69b6826a190505d2a1dd3fe79c90b
|
|
Change-Id: I276f7bbf2bd6fa7c67d8691634ad9d79e4a08b1c
|
|
... and way less overhead, geez..
Change-Id: Id9277301fbe69bc9a83ca39a907032b0b86b1c81
|
|
Since f82d89f35207fc1cfc00ad5cd914b74c55c3e3d2 EditThisFunc() and
EditNextFunc() are used to iterate through the formula to obtain
expression results to display in the treeview. Calling the Edit...()
functions spoils about everything as it messes around with the edit
state. As the name suggests..
Change-Id: I8b35d85b7bbf8821b5a995e84f9dd88a0f6f00b9
|
|
Currently the Function Wizard is broken in that editing a function call
as argument within another function's parameter leads to selections
being reset and mismatching argument/function information being
evaluated. Not sure yet what's going on there, but at least don't access
vectors out-of-bounds or crash.
Change-Id: I633c775556a0b90278d22d0f74d2975c20a08a5d
|
|
Change-Id: I15843b320ac8ddcefce8094da7aa7c6b81b42e4f
|
|
Change-Id: I56c66f516ba2a2e12cab4848c8c352315f27b3bb
|
|
Change-Id: I2ae13771c85044b771e253a8189a30cb4aecb30f
|
|
... if literal strings are copied with formula expression tokens.
Change-Id: I13526907bb6c2c605c6ed9584fa6e3f2b18623b8
|
|
Change-Id: Ic7af56ac801c1e5b3fcf3c4e8413656e96220279
|
|
Change-Id: Ic06bef4c80426b97a2613fe296ae0aa0ee55a215
|
|
... to name it was it does and to distinguish from
ScParameterClassification::HasForceArray(OpCode) which IS about a
function having ForceArray parameters.
Change-Id: I8af4e1d0353cdb5ad0a9b837ae0763dc77242734
|
|
This may happen if the last RPN token is put and the function has a
ForceArray parameter but now again would be wrong if not all parameters
are ForceArray.
Change-Id: I890fb6b5b88337033cfcf2e8189371ee39461205
|
|
Regression of b5cd11b4b02a85a83db77ba9d8d1763f0cd88cb1
It was always wrong to propagate ForceArray already if a function had a
ForceArray parameter *somewhere*, we need to do this per parameter
instead.
Change-Id: If188d45366279d9a7bf641edc7e4dd7095d6d035
|
|
Following http://cgit.freedesktop.org/libreoffice/core/commit/?id=844b7287a4ccd8e3d5e458bb1dc6c52e71322b01
Change-Id: Ia5a2cd39cf3fdf87619f55710a188545830b4088
Reviewed-on: https://gerrit.libreoffice.org/19970
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
replaced using:
git grep -lP 'Sequence.*OUString.*\(\s*1\s*\)'
| xargs perl -0777 -pi -e
"s/Sequence<\s*OUString\s*> (\w+)\(\s*1\s*\);
.*\[0\] = (\S+);/Sequence<OUString> \1 { \2 };/g"
Change-Id: I20ad0489da887a9712982531c3b127339bb8b3b9
Reviewed-on: https://gerrit.libreoffice.org/19969
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ife26f55c28c4631aec4ba4105225bfca72da8bff
|
|
Change-Id: Ib336ce9bc95f5c84dd6412ff3c098e68c5b0f4ff
|
|
Change-Id: Ied06b3f167c566d754d32708eaec4a354f7ee663
Reviewed-on: https://gerrit.libreoffice.org/19848
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
This reverts commit bebc20c62be2df2cf2741fb82945ce6b631d2fe5.
Removing the disabling is plain wrong. Please see the code for when the button is disabled, when it is enabled, and what consequences it has when changing the state from checked to unchecked. Unchecking will result in the formula not being applied as array formula anymore, which it was before editing.
Actually tdf#90695 is not even a bug. The checked but disabled Array button is meant as an indicator that the formula IS an array/matrix formula.
Change-Id: Ic7f9f7010ce208171ef614e0885474f2deae4ac9
Reviewed-on: https://gerrit.libreoffice.org/19602
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Just remove the disabling
Change-Id: Ia03591610ba1b60a66d9962169383c4ab85288ca
Reviewed-on: https://gerrit.libreoffice.org/19590
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I4cb8e39dfe7efcb7ac75ebf41e3d76b8f12750f2
|
|
Change-Id: Icbba339dac0be31e30dff021bba06a219f8aecd6
Reviewed-on: https://gerrit.libreoffice.org/19405
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I211687bfeaf456e0f9639567bff401083011cd74
Reviewed-on: https://gerrit.libreoffice.org/19353
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
... setting a control's background color has no effect (until input
field text is changed?)
Could be observed in the pivot table dialog's source range edit when an
invalid range was entered.
Change-Id: Iafb2a9016ac6bd4c020273911d62dd7423ee0458
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Change-Id: I328ac7a95ccc87732efae48b567a0556865928f3
|
|
Change-Id: Iec15042138e0715459b2c9e872a7464d75a6b1eb
Reviewed-on: https://gerrit.libreoffice.org/19305
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia4c09c5b835e77eaa2d4c0d8c74f146feb0905be
|
|
... so we can get a little bit more verbose. The new "this is for
interop with old ... instead use ..." description fit into the function
overview but was truncated in the parameter window.
Change-Id: I73c5e6cfb64a2b1573ab15f5ceb6aa16e6da4a99
|
|
Change-Id: I273aee2d65f952afd78f6e2e504b5fa70dd65ef0
|
|
Change-Id: I6a903931fdb3ac1b13d2d9c39071cc27c08fe194
|
|
make Calc function WEEKNUM compliant with ODFF1.2,
provide backward compatibility for Calc function WEEKNUM,
add unit tests for ISOWEEKNUM, WEEKNUM and backward compatibility.
Change-Id: I63af5543cea2f470d710462e55404ac754022c89
Reviewed-on: https://gerrit.libreoffice.org/18760
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
This seems to give about 10% performance improvements in some calc cell
calculations.
Change-Id: Ibd91558b3c107e4c8e1401345c9332f97645453e
|
|
Fixed tdf#94269
Change-Id: I63109cc4e095bad680d7637a065080ea368860ae
Reviewed-on: https://gerrit.libreoffice.org/18851
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
(cherry picked from commit 48cb20bb5c32f076f295c7490d6ba9ac96e85ed0)
Change-Id: I18ba8a781e111fd7706de1eadb41c93a78e27c62
|
|
Change-Id: Ic053342fde436a7053c15e32683e09b9e91f5308
Reviewed-on: https://gerrit.libreoffice.org/18792
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I59d325c3b051690303a5841907317122fa1ec98b
Reviewed-on: https://gerrit.libreoffice.org/18825
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I70de366349801fed36fb5d62bc53236efa8b6967
|
|
Change-Id: I93988860f409e13d99aaec06a0b0833b3814da24
|
|
Change-Id: I6aee7b6ede35aa590a263c3851d181115233a790
|
|
Change-Id: I0521aad1bc63c75242ae07feccebe24dbc754d6b
|
|
Change-Id: I8465811de6794345d79eb29c8efbc70f82b3168e
|
|
Change-Id: Ia2e3180b8794e0875869640ae0c45026718c1946
|
|
Change-Id: I83a418c81a5d1267286236cfcdedc889d34fc963
|