The odd one out is the usage in Formula, which attempts
to restore focus to a particular window identified by
an unique id. In this case restore focus by keeping a VclPtr
to the desired window.
Change-Id: I1dc335325c109d75745c6bba2e12662e6ae50638
The array overflow detecting places that unconditionally deleted the
token in case of overflow should do so only if no reference is held,
i.e. the token was allocated with new and passed immediately without
being assigned to a FormulaTokenRef. Just to be on the safe side.
Change-Id: If2ccabec3725ac73fe82c23f51a291246847cfdb
Also when reading/writing OOXML, so change SC_OPCODE_INTERSECT of
RID_STRLIST_FUNCTION_NAMES_ENGLISH_OOXML accordingly to " ", where
previously "!" was expected and written, which was plain wrong.
Change-Id: Ic0cfd7afc657f07bfd8e37de61b3621cc68685ff
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
This does not solve the difference in how Excel seems to handle the
arguments and calculation, but some corner case. See bug comment 6.
Change-Id: Ifa331e8552587c40e1486a08093ed0df92a9d245
* in a spreadsheet cell enter =LOG(foobar(SIN(1)))
* invoke Function Wizard on that cell (Ctrl+F2)
LOG(foobar(SIN(1))) is marked in Formula edit field
* activate Functions page
LOG(foobar(SIN(1))) is marked in Formula edit field
Function LOG is selected
* click Next button
foobar(SIN(1)) is marked in Formula edit field
Function ABS is selected
* click Next button
foobar(SIN(1)) is overwritten with ABS( )
* only Cancel solves the problem
foobar() could be any user defined or macro function that have no
function description in the Formula Wizard.
Change-Id: I1cb69a9e38c0b8f251d783bd0f67b4b24ade50d0
... instead of a temporary instance and AddToken() that just clones it
again.
Add function comment describing the difference.
Change-Id: I3f089965d394b33d7bbbb9a1c3f69dc1c4182fd2
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
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
... to name it was it does and to distinguish from
ScParameterClassification::HasForceArray(OpCode) which IS about a
function having ForceArray parameters.
Change-Id: I8af4e1d0353cdb5ad0a9b837ae0763dc77242734
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
includes should be able to be included on their own
fix some of the ones that do not respect
that rule.
Change-Id: Id161224a1978461d3cea43252f232f18888a4f61
Reviewed-on: https://gerrit.libreoffice.org/19612
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
