summaryrefslogtreecommitdiff
path: root/sc/source/core
AgeCommit message (Collapse)AuthorFilesLines
2016-04-12(re)broadcast if value replaces cell of grouped formulas, tdf#97897 relatedEike Rathke1-0/+5
Replacing a grouped formula cell with a different content may lead to the remaining cells of the group not being recalculated if they listen to a range that contains the current position. For example A1: 1 A2: =SUM($A$1:$A1) => 1 A3: =SUM($A$1:$A2) => 2 Enter 2 in A2 => A3 should be 3 but is not recalculated. Loading http://bugs.documentfoundation.org/attachment.cgi?id=122714 of tdf#97897 exhibits that behavior. Change-Id: I10b91e77549a7534143be3d6e3cc03026cdaa764 (cherry picked from commit ce28d83912d14bc81c455af64893842de78a8c8d) Reviewed-on: https://gerrit.libreoffice.org/23856 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-12(re)broadcast, same as in ScDocument::SetString(), tdf#97897 relatedEike Rathke1-0/+5
As with ce28d83912d14bc81c455af64893842de78a8c8d Change-Id: I7cd30509138368d73b43c82d71d520d55417d416 (cherry picked from commit b6ba851c02570c17e0484c94065a2e72c5675e58) Reviewed-on: https://gerrit.libreoffice.org/23870 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-12Resolves: tdf#98990 accept R1C1 notation entire column/row referencesEike Rathke1-5/+9
... which consist of only C4 or C[3] without a range operator. Change-Id: I1865f0ec4c4fec1101b93b6b40d6f26871a65f07 (cherry picked from commit 3c36ba50f65d663f35264f2a11c99c0ff98674a2) Reviewed-on: https://gerrit.libreoffice.org/23843 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-04-08add a recursion guard to lcl_FindRangeNamesInUse()Eike Rathke1-5/+9
Change-Id: Ifbc02304f5a2e080db2d6645e2c7f825a2c56cb5 Reviewed-on: https://gerrit.libreoffice.org/23473 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-03-31tdf#92963 Pasting a whole row with data crashes all open LibO appsArul Michael1-0/+7
In ScColumn::GetNeededSize the memory pointed by rOptions.pPattern is freed and new value is set again in ScFormulaCell::InterpretTail function in pDocument->SetNumberFormat when pDocument->GetCondResult is called in column2.cxx:130.For fix setting the newly calculated ScPatternAttr* value after the GetCondResult call. Change-Id: I045404465b6dfa561b0821bb3b1875463aa7887a Reviewed-on: https://gerrit.libreoffice.org/23688 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com> (cherry picked from commit 99bf0b931401f556033f67297aa9783c4cf19b00) Reviewed-on: https://gerrit.libreoffice.org/23709
2016-03-28Resolves: tdf#98642 comparing RPN insufficient in shared formula detectionEike Rathke1-1/+46
(cherry picked from commit d6b32653ad34f0879ad1ada421a3a2655dd766e1) Backported. Change-Id: I78812c2d6fdb3464ccc2ebeee901a76f675effa4 Reviewed-on: https://gerrit.libreoffice.org/23437 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-03-24fix the "group not recalculated after delete" second part of tdf#97897Eike Rathke1-0/+18
If a formula cell group was split during deletion and the group also listened into the range where a cell was deleted, the group wasn't notified of the deletion. Change-Id: I858f5d4c0b647636611133fc32f3df7fbdaf7288 (cherry picked from commit 164419bfe6270015ccf94183c0b6273da7730391) Reviewed-on: https://gerrit.libreoffice.org/22784 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-03-18ensure a correct index is assigned to a duplicated ScRangeData instanceEike Rathke1-0/+1
ScRangeName::insert() assigns an index only if the passed ScRangeData instance's index was 0. Duplicating an ScRangeData object duplicates also the index, so effectively two instances with the same index could be inserted to the named expressions collection, a following ScRangeName::findByIndex() retrieved one of them by chance. Change-Id: Ic141ffb1a683bda5907f4359167da84faf1649e1 (cherry picked from commit 336d816176650726f6d14539464d9fd28ddd032d) Reviewed-on: https://gerrit.libreoffice.org/23324 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-03-15Resolves: tdf#93196 add RecursionCounter guard also to InterpretFormulaGroup()Eike Rathke1-19/+29
... same as for ScFormulaCell::InterpretTail() Change-Id: I444f259fe4e86ed0638a04f1b5d9272edd182e2e (cherry picked from commit 29ee431c1cf859c3d5a5041cff5cb04b89db27a0) Reviewed-on: https://gerrit.libreoffice.org/23280 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-03-09Resolves: tdf#95226 second case, stack error count in JumpMatrix contextEike Rathke1-0/+14
For the early bail out on errors to work correctly and not prematurely end calculations the current error function needs to be stacked in JumpMatrix context, otherwise we may end up with ((nErrorFunction=74)>=(nErrorFunctionCount=2)) or some such.. (cherry picked from commit 62b40429946c0e5021912072dc79a60fc11fce06) Change-Id: I3559e15180694961585db92f6aa98a46430ae372 Reviewed-on: https://gerrit.libreoffice.org/23091 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-03-09Resolves: tdf#98297 exclude error values from COUNT in array/matrixEike Rathke2-8/+24
Backport of b2f5336b08b5f638f890a626eb2aeefaf499a79b Change-Id: I04ef53b8880243b3548e1b7fd926690dcb4a2137 Reviewed-on: https://gerrit.libreoffice.org/22846 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-03-09Resolves: tdf#98389 check memory requirement of matrixEike Rathke1-8/+35
Attachment 123203 of tdf#98389 has external references of the form [1]Data!$1:$1048576 which effectively address the entire cell range of sheet Data and allocating a matrix for a billion cells attempted to allocate 8GB+xGB of memory which the system said no-no ... Some brave soul along the road once decided that a check on the number of elements wasn't needed anymore and dared to remove it during refactoring.. This change reintroduces the check and adds it also to other places that try to instanciate or resize a matrix. When allocation of a matrix for an external range reference fails it is checked whether the request is for such nasty entire rows or entire columns ranges and if so tries to shrink the range to the actual data area used, which at least in this case helps and works. Additionally it fixes a long standing bug in the cached area to array mapping which caused the cache to not be hit but instead the matrix was aquired over and over again for the same range, causing a serious performance bottle neck specifically for VLOOKUP and related functions where the same external range is used in a lot of cells. (cherry picked from commit 9e60bbdb3aa5f80ca80c9c4fdf7accd12c4a5d1c) Change in convertToTokenArray() backported to older code flow. disable means Enable(false), not true.. tdf#98389 related EnableAdjustHeight(true) lead to the side effect that when clearing the range of a pivot table during import, formulas in the same rows were recalculated with then empty data. Through xSheetOp->clearContents() in PivotTable::finalizeImport() of sc/source/filter/oox/pivottablebuffer.cxx In the case of the bugdoc attached to tdf#98389 that lead to all VLOOKUP() calls resulting in #N/A errors because an empty string was looked up. (cherry picked from commit 088ba465d6bb0931c7034d564a3077e21078cb13) e629ce871d255cc871671165c4da974f21041cec Backported to ScMatrix implementation of 5-0. setCellRangeData: check matrix size before operating, tdf#98389 follow-up Now that we can have the one element error matrix we can't blindly call ExecuteOperation() on it that would access elements out of bounds. (cherry picked from commit 9cae3a88587deaf22ee83b2e36487013a1220a3b) Backported to older code flow. b6e5525f685c9324235f128a943dd716ea7a3fca Change-Id: I35f67b48e665bf1cc8d672325c32b889f2e05c57 Reviewed-on: https://gerrit.libreoffice.org/23003 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-02-02tdf#97150: tdf#94924: If we can't handle strings, don't try to thenTor Lillqvist1-0/+7
Fixes the VLOOKUP problem reported in tdf#94540 by falling back to non-OpenCL for such a case, where one of the columns passed to the VLOOKUP contained strings. And since a while, we don't claim to handle strings in VLOOKUP. Which is true. (cherry picked from commit 476bef70f1d9fd58b29a1f6fb95e54567b031acf) Change-Id: I4140c86bf8166beb8201aa90c075d9f4432d9173 Reviewed-on: https://gerrit.libreoffice.org/21874 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-02-02Resolves: tdf#93151 handle ExpandRefs and mnColDelta the same as mnRowDeltaEike Rathke1-9/+93
(cherry picked from commit 02e69f0c3acec2c2e81692bc53c4356591a84ba5) Conflicts: sc/source/core/tool/token.cxx Change-Id: I8cd00494fc63124443fc01582296ef17f4cd5e27 Reviewed-on: https://gerrit.libreoffice.org/21821 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-01-25tdf#96910 : Calc crashes while using "Insert Column Left" for large DocumentsYogesh1-5/+7
Change-Id: I6e813b7525a3d9b1db131db9f08fc20f7320345f Reviewed-on: https://gerrit.libreoffice.org/21661 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com> (cherry picked from commit 208883398dcf9af6b88611097d1f75d5fbc9afad) Reviewed-on: https://gerrit.libreoffice.org/21792 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2016-01-25tdf#97308: fix logic with conditional "ends with"Julien Nabet1-2/+2
Change-Id: Ib9f9ed627dc37b11d8c3911aa4fe62141ff471c2 Reviewed-on: https://gerrit.libreoffice.org/21723 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr> (cherry picked from commit a0a4ea3c636fc18cca6a3b2f9391996fb909e81f) Reviewed-on: https://gerrit.libreoffice.org/21731 Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-01-18tdf#96198 accept WEEKNUM with only one parameter, tdf#50950 follow-upEike Rathke1-2/+5
Loading ISOWEEKNUM(date) maps to WEEKNUM(date) so accept the actual ISOWEEKNUM parameter count defined in ODFF. This also ensures forward compatibility with 5.1 where 3e5deb8ccfaf0b73fb6cf394822e560dc036a686 (cherry picked from commit 15494f0f99d1cf6f75e8c2996377b242af247bbf) converts ISOWEEKNUM(date,mode) to real ISOWEEKNUM(date) if mode!=1 as there is no matching WEEKNUM(date,mode) defined. This WEEKNUM here never implemented the ODFF WEEKNUM but a mix of ISOWEEKNUM and something undefined different. Change-Id: Ibd0d4483486a1db28cc600821baae9f13b9dd687 Reviewed-on: https://gerrit.libreoffice.org/21118 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-01-12tdf#90606 Crash when delete a large part of a column with shift cells leftArul1-6/+15
skipping splitFormulaCellGroup() and joinFormulaCellAbove() for nEndRow equal to MAXROW since nEndRow + 1 is not valid Change-Id: Iabfcb33bf58d20331841ca386cca4a91fd6598bf Reviewed-on: https://gerrit.libreoffice.org/21389 Reviewed-by: jan iversen <jani@documentfoundation.org> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com> (cherry picked from commit 975ceab198a06558875006bbd9a4d0a2708e416e) Reviewed-on: https://gerrit.libreoffice.org/21393
2015-12-16Resolves: tdf#95440 SharedString are interned per document, re-internEike Rathke1-0/+4
... if literal strings are copied with formula expression tokens. (cherry picked from commit dad412e07f805a53ad73ce2e80d187a70c77e8de) Conflicts: include/formula/token.hxx Change-Id: I13526907bb6c2c605c6ed9584fa6e3f2b18623b8 Reviewed-on: https://gerrit.libreoffice.org/20731 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2015-12-04tdf#83126: Find All: Don't ignore Search Direction Rows/Col optionJulien Nabet1-1/+1
bAll (ie "Find All") seems a little tricky for GetBackward but not for GetRowDirection method Change-Id: I47d2b378fb493bcdc1ad30902a3a677eedc50789 Reviewed-on: https://gerrit.libreoffice.org/20067 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr> (cherry picked from commit 71f0e4e5e2efee05bccf13698752e84f5059db5f) Reviewed-on: https://gerrit.libreoffice.org/20105 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2015-12-03Resolves: tdf#95748 no group interpreter when calculations are runningEike Rathke1-1/+9
(cherry picked from commit d46203b55d92185ab2c1d3ac79761100d26aaee3) Conflicts: sc/source/core/data/formulacell.cxx Change-Id: I17283fc5e39da2d7222c302dd63522df69d0ad96 Reviewed-on: https://gerrit.libreoffice.org/20328 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-11-23tdf#94214 ODFF function FINV incorrectly saved as COM.MICROSOFT.F.INVWinfried Donkers1-1/+1
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> (cherry picked from commit 5ba0f79e246ea970d16f366640c2ccd87e1d8786) Backported to 5-0 replacing the interim forward compatibility of 4a33435137e4d9fb7a85c527a37edc6780170d9a Change-Id: Ic053342fde436a7053c15e32683e09b9e91f5308 Signed-off-by: Eike Rathke <erack@redhat.com>
2015-11-20Resolves: tdf#95670 propagate ForceArray per parameterEike Rathke4-3/+13
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. (cherry picked from commit 49257e1da7e371fdea0fac080116b0511789cac7) Conflicts: formula/source/core/api/FormulaCompiler.cxx prevent ForceArray propagation on the same token, tdf#95670 follow-up 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. (cherry picked from commit b31b17e52b2b2b94999d68c4b2ed5c74ee7eed0a) 890fb6b5b88337033cfcf2e8189371ee39461205 -Werror,-Winconsistent-missing-override (cherry picked from commit 6edc492efd6fe2de15c1ae306b400ca054772ad1) Backported to SAL_OVERRIDE 3bb2764b625d44f6e0cecbdde3363440faef63b5 Change-Id: If188d45366279d9a7bf641edc7e4dd7095d6d035 Reviewed-on: https://gerrit.libreoffice.org/19993 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2015-11-02Resolves: tdf#95395 force range reference to array only in array formula, ↵Eike Rathke1-1/+7
also tdf#95419 ... and not already if the function has a (ReferenceOr)ForceArray type parameter somewhere else in the parameter list. Regression triggered by commit 01eea7fe40c939311bf1920b6e8b4391a93c2e82 for MATCH, HLOOKUP and VLOOKUP first parameter, but behavior already present since OOo for LOOKUP; FORECAST in its first parameter, PROB, LINEST, LOGEST and TTEST in the last two parameters. Change-Id: I4a30ea3362f86274a048b0e3f47fa12da3001a3a (cherry picked from commit b5cd11b4b02a85a83db77ba9d8d1763f0cd88cb1) Reviewed-on: https://gerrit.libreoffice.org/19659 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2015-10-24tdf#32834 : improve the precision of MDETERM calculationDennis Francis1-4/+5
MDETERM uses lcl_LUP_decompose() which as the name suggests does LUP decomposition. This patch allows additive cancellations to occur in a cleaner way while doing the *only* additive operation in LUP decomposition, that is while computing Shur complement. This patch does not change the high level semantics of the algorithm. Also note that this change makes improvement only in the case where matrix elements entered by the user are *integers*. The change allows MDETERM to evaluate to exact 0.0 for singular integer matrices. The steps to calculate Shur complement are : for i = k+1 to n aik = aik / akk; for j = k+1 to n aij = aij - akj*aik This is now modified as : for i = k+1 to n for j = k+1 to n aij = ( aij*akk - akj*aik ) / akk Without this change MDETERM() for certain singular matrices used to evaluate to a tiny non zero value, which also caused MINVERSE() to generate a wrong output. An example of such a matrix is : 1 2 3 4 5 6 7 8 9 Change-Id: Idd4211ddceab1b758fd05bfd57f7eecd5d4fd1a0 Reviewed-on: https://gerrit.libreoffice.org/19534 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com> (cherry picked from commit e1e73a97b20af862f2fb914cb16a4f74c3ad31cb) Reviewed-on: https://gerrit.libreoffice.org/19578
2015-10-22Resolves: tdf#91453 use configuration of text to number conversionEike Rathke5-282/+332
... also in arithmetic matrix operations. (combination of 4 commits): move ConvertStringToValue() implementation from ScInterpreter to ScGlobal In preparation of matrix calculations to use string conversion configuration and UI markers for cells containing strings that could be numeric values. Change-Id: Ifa9e45853dded249fa741c050ae1f106365f99ea (cherry picked from commit 329496c1f75f97d2e6119ceb214a2ea1fbadb17a) add half decoupled ScInterpreter::ConvertStringToValue() ... for back calls of ScMatrix in preparation of tdf#91453 Change-Id: Ife94d1675c1bc7c5611586e3f352ff69264469d7 (cherry picked from commit 6516d5e299bdf0e7aa03d1004763f6d10db48546) Resolves: tdf#91453 use configuration of text to number conversion ... also in arithmetic matrix operations. Change-Id: Ia00054d0af383e225d9d40b59da2dc28a817b65a (cherry picked from commit 466a20ef07f36d50a73a18ab119b3cc18b4babf4) Resolves: tdf#91453 use configuration of text to number conversion ... also in arithmetic matrix operations if both operands are matrix. Change-Id: I84609656b166b4e059d9496a5ed732a96e731164 (cherry picked from commit 778d03b59c62d21fd171b81c9fab3ba8496e319d) Reviewed-on: https://gerrit.libreoffice.org/19172 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2015-10-22Resolves: tdf#95226 fix broken IFERROR/IFNA array logicEike Rathke1-2/+3
Change-Id: I059248659f51746cfc1d06faeaadaf3d645c03d3 (cherry picked from commit 968e2faff6d4283dacd9010d31cb4c0df45eb7c5) Reviewed-on: https://gerrit.libreoffice.org/19519 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-10-16tdf#94924: Return correct result 0 from OpenCL MIN and MAX when all args emptyTor Lillqvist1-5/+24
Used the same style as existing code, added a new virtual isMinOrMax() and add some special casing in Reduction::GenSlidingWindowFunction(), and fsim_count() and fmax_count() functions that count how many non-NaN numbers we actually see. As such, I am not sure at all that this is an ideal way to do this, but will have to do for now. Change-Id: I846a8d24f4563f8fae1a45971a4ce202ed918487 Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
2015-10-16tdf#94924: Return correct #DIV/0! error from AVERAGE in the OpenCL caseTor Lillqvist1-1/+5
Change-Id: If7326fd1242d90ff92e62d141714960476198605 Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
2015-10-16tdf#94924: Fix handling of empty cells in OpenCL divisionTor Lillqvist1-8/+4
Not sure why the code from f5e7207053b857b6903a0ab9c161bed9ad7bcee9 did not produce correct results any longer. Anyway, now OpenCL division works right in case of empty or zero cells. Clearly I need to add unit tests to make sure this stuff keeps working. In later commits. Change-Id: I93b787ad5da453af1601768308fb614a332ed142 Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
2015-10-16tdf#94924: Fix handling of empty cells in OpenCL subtractionTor Lillqvist1-14/+2
We get correct result by simplifying the code;) No need to have the outer "if (gid0 < X)" test around the calculation code generated by Reduction::GenSlidingWindowFunction(). The lhs and rhs check the gid0 range themselves and that leads to the desired result for subtraction. While fixing this I noticed that the handling of empty cells in division is also wrong. Will fix in another commit. Change-Id: Ia45bd81e692a17b0453cc79cd4673a00e119562a Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
2015-10-14Resolves: tdf#94514 more restrictive check on end of column specifierEike Rathke1-1/+1
... needed since we accept A:A entire column notation without the need of a row number being specified. Change-Id: I84f6a39e213a4b554e0188e73b4acb34c7a98460 (cherry picked from commit 14bb562b4a8776974391641adcc62ded013ffd2f) Reviewed-on: https://gerrit.libreoffice.org/19359 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-10-12tdf#93688: Set CalcA1|ExcelA1 syntax only for imported docsKatarina Behrens1-4/+3
those whose string ref syntax is unknown or can't be guessed i.e. don't use it for new documents (prefer user settings in that case) Conflicts: sc/qa/unit/subsequent_export-test.cxx Change-Id: I1355031cdd63e2a5c50064531011be71ae7f7b8f Reviewed-on: https://gerrit.libreoffice.org/19244 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2015-10-12crashtestig: infinite recurse in ooo32833-1.sxcCaolán McNamara1-1/+4
integralPhi is called with nan(0xfffff000001f6) which recurses through rtl_math_erfc->rtl_math_erf->rtl_math_erfc until we run out of stack Change-Id: Iab8a22fb23686d22d151f2508dbeb44ab47a76b7 (cherry picked from commit d2a07cd3214af27c5af601992e3c4a1a6e3b3dad) Reviewed-on: https://gerrit.libreoffice.org/19282 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2015-10-09crashtesting: ooo95537-1.xls fails with a fAnz that is nanCaolán McNamara1-5/+5
so it happily passes the pre-cast string bounds check and blows up in the post-cast string access Change-Id: Ifd4d087b37e8a84d886e2f7833dfc773b8bf1343 (cherry picked from commit 5d826db15beaff4f0930724431d34f7103111591) Reviewed-on: https://gerrit.libreoffice.org/19280 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2015-10-09Revert "Resolves: tdf#94869 propagate error when obtaining a scalar double ↵Eike Rathke1-15/+7
value" This reverts commit bfd51e38599d717a3c1b19acd882b52175dd3d09. Calculating with NaN cries for even more problems.. Change-Id: Ie1b7cddc4f157859ee3087b0eadb3a082672a1c7 Reviewed-on: https://gerrit.libreoffice.org/19286 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2015-10-09Resolves: tdf#94796 LINEST and LOGEST have ForceArray parametersEike Rathke1-2/+2
Change-Id: I6bd82191ef7c5bb2c7829daf341d360c6d09c11b (cherry picked from commit f3dfab0c23bde81a00fa2f16cf4d96c8809e5045) Reviewed-on: https://gerrit.libreoffice.org/19237 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-10-08Resolves: tdf#94869 propagate error when obtaining a scalar double valueEike Rathke1-7/+15
... if any operation like popping a value or calculating an intersection resulted in error, so the error gets passed as double error to matrix operations where one operand is a scalar value. Change-Id: I909ba25545625b827ce790e07d1ebe8643154703 (cherry picked from commit 934e47958c78d1184beaaefdf3baefd3eecbea05) Reviewed-on: https://gerrit.libreoffice.org/19235 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-10-05Probably good to move the more complicates test after the light-weight onesTor Lillqvist1-3/+3
We will return false if any of the tests here match, so good to test the trivial things first before ones involving a potentially complex function call. Change-Id: I531282041c888799d37d95ae773daa349e60a37d
2015-10-05tdf#94173: Calc doesn't save your own created autoformat presetsJulien Nabet1-0/+10
Auformat list (maData) is defined as "MapType" which itself is defined like this: boost::ptr_map<OUString, ScAutoFormatData> so default sorting is ascii 2 consequences: 1) Default didn't appear first 2) When adding a new autoformat entry when it was new first one of the list wasn't saved because of iterator was incremented first before looping See https://bugs.documentfoundation.org/show_bug.cgi?id=94173#c5 There were some other weird behaviors too according to comments of the bugtracker Regression from http://cgit.freedesktop.org/libreoffice/core/commit/?id=72c1b6141d590fb4479925ed8bc88b79357c2bfc Solution: Add a Compare so Default entry is always first one so the first time incremented iterator is ok and new entry (even if new first one in list) is saved Thank you Markus for the idea! (I was lost in Compare syntax) Reviewed-on: https://gerrit.libreoffice.org/18598 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr> (cherry picked from commit 652158c3f2c9cd0d6f71ecd14bf5d5cc02a71b50) use collator for UI visible sorting, tdf#94173 follow-up (cherry picked from commit a71febc99d2cfc2fe51dec8c0bca5d84d8577168) b9f7ebb087c1ce5008f43b2df3f1fadc41066ed1 Change-Id: I9ba0cdc63c66b747db102bb661cd09fbfe5996ae Reviewed-on: https://gerrit.libreoffice.org/19029 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2015-10-01don't try to create OUString from editeng directly, tdf#94542Markus Mohrhard1-2/+6
editeng uses special control characters (apparently 0x01) that need to be translated by editeng to the real characters. Let EditEngine handle the conversion from editeng string to OUString. Change-Id: If5014e1ada7f1df933a084b17bb307035ce01cc6 Reviewed-on: https://gerrit.libreoffice.org/19065 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-09-28follow up of tdf#94214Winfried Donkers1-0/+1
provide forward compatibility for name change of FINV Reviewed-on: https://gerrit.libreoffice.org/18814 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 2cc040878ce816b0353224910333e33a20983359) Conflicts: sc/source/core/tool/compiler.cxx Change-Id: I0afd2555be94c452172e5a357f2f0897be381863 Reviewed-on: https://gerrit.libreoffice.org/18909 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2015-09-25fix IterateMatrix for ifPRODUCT and ifSUMSQEike Rathke1-1/+2
... if more than one argument is passed to PRODUCT() or SUMSQ() and matrix/array arguments are involved the functions returned wrong results. For example, wrong behavior =PRODUCT({2,3},{4,5}) gave 6 =SUMSQ({2,3},{4,5}) gave 34 Correct is =PRODUCT({2,3},{4,5}) result 120 =SUMSQ({2,3},{4,5}) result 54 Change-Id: Iec7b136a5cc678416f28b1abfe19cd0901ef22b6 (cherry picked from commit c1780ad265ce5f6abb3b91a4f70bf2b3d7a47149) Reviewed-on: https://gerrit.libreoffice.org/18864 Reviewed-by: Łukasz Hryniuk <lukasz.hryniuk@wp.pl> Tested-by: Łukasz Hryniuk <lukasz.hryniuk@wp.pl>
2015-09-17Resolves: tdf#94249 do not remove broadcasters while iterators are in useEike Rathke3-12/+19
EndListeningContext holds BroadcasterStoreType iterators in its ColumnBlockPositionSet and collects broadcasters to purge them at the end. Removing broadcasters from ScColumn::maBroadcasters in between invalidates the iterators. Hence calling the "normal" EndListening() that removes a broadcaster when all listeners are gone while an EndListeningContext is in use is bad. Change-Id: Ibdd88469e91e6173ceff1f391c23ef7cb7c6f596 (cherry picked from commit e4a8ae0bf54476e9a0c9e1f5348c05f3cd838899) Reviewed-on: https://gerrit.libreoffice.org/18615 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-09-17Resolves: tdf#93895 broadcast cell changes when multi-selection was pastedEike Rathke1-4/+12
It is not sufficient to collect the cells, one has to broadcast on the collection. Change-Id: I11f889936aff43f958c56789e539809289819752 (cherry picked from commit 97ad6393525a928b5dfe2a6562d7604446da7af0) Reviewed-on: https://gerrit.libreoffice.org/18573 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2015-09-16Split formula group for OpenCL up into smaller bitsTor Lillqvist1-20/+116
Will make it less demanding on low-end hardware, where the device driver is unresponsive for too long when a OpenCL kernel handling lots of data is executing. This makes Windows restart it which is problematic. I tried several approaches of splitting, both at higher levels in sc and at the lowest level just before creating and executing the OpenCL kernel(s). This seems to be the most minimal and local approach. Doing it at the lower level would have required too much poking into our obscure OpenCL code, like passing an offset parameter to every kernel. Use a simple heuristic to find out whether to split. On the problematic low-end devices, CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT is 4, while for more performant devices it is 1 or 8. Change-Id: If16d152710057b34d09ef0203960e1fbb9ac067f Reviewed-on: https://gerrit.libreoffice.org/18613 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>
2015-09-15tdf#94079 allow empty array for holiday sequenceWinfried Donkers4-12/+16
in Calc functions NETWORKDAYS and WORKDAY.INTL Change-Id: I2d42ab956e4ab9f2187a0c6bc3c64c9306ca892a Reviewed-on: https://gerrit.libreoffice.org/18559 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com> (cherry picked from commit 75bde904d5b4f756037889f2b2ddee3e34dd81b8) Reviewed-on: https://gerrit.libreoffice.org/18595
2015-09-11Resolves: tdf#92995 do not delete caption objects that are held by UndoEike Rathke3-3/+25
Drag&Drop Undo is a special case of ownership.. Change-Id: I2fe7769c4d84efe09d432335d5d8e72d506bf7a1 (cherry picked from commit 44f34c1163882c2e3086282374fee9cd55ee211f) Reviewed-on: https://gerrit.libreoffice.org/18470 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-09-01Fix the OpenCL VLOOKUP to work properly and add it to the trusted subsetTor Lillqvist4-93/+103
Treat an array of null string pointers as no strings for OpenCL. For some reason, at least in the case of the "Test OpenCL" thing, we got an mpStringArray that is non-null but where all the elements (rtl_uString pointers) in it are null. Treat that case as if the mpStringArray was null. This makes the tests "Test OpenCL" actually use OpenCL. Maybe it has other useful effects, too. (But for normal spreadsheet use, the mpStringArray that gets handled here *is* null when all the cells used by a formula group are numbers. At least it seemed so in a simple test.) Add a few more useful (?) SAL_INFO calls. Some cosmetic changes to make the code look saner. Return correct value from the OpenCL VLOOKUP implementation. Also, when the lookup fails, produce the expected N/A error code instead of a bare NaN. Don't claim we support strings arguments in the OpenCL VLOOKUP. The string support certainly isn't complete or correct anyway. Partially revert c3383aafa18ef9d03b04b2a4719e71fdfabc14eb. Add VLOOKUP to the set of opcodes that we trust the OpenCL implementation for. (cherry picked from commit 7e91726f4d81f0ab27d79ee231abd666b4999758) (cherry picked from commit d4310b6cd8a367666cc702c3e47cf12a35407ef7) (cherry picked from commit 32b35d9d8a21091b987d94fc2ad24d69e9d8a6f3) (cherry picked from commit 41a6094095a0cd42f24eb996c7ec8c28ab9d6c1a) (cherry picked from commit 162264450cb62177ea133829d081fecdb02136b5) (cherry picked from commit 7bb7539c0e34283baeaacf7e4ff0b19287afadc2) Change-Id: I5402732c9ddcac1efcc25960a5c46175d7a90b4d Reviewed-on: https://gerrit.libreoffice.org/18022 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2015-08-31do not parse range fragments as valid rangesEike Rathke1-2/+9
For example, "B2:" or ":B2" were accepted as valid range, with the missing part set to A1, which resulted in a A1:B2 range. An omitted sheet specifier always results in a valid relative sheet, hence that flag is set, so testing flags for non-null before the final result is available isn't sufficient. Additionally this revealed a flaw in handling of external references when loading documents if the original file name differs from the resulting real file name due to relative paths. Actually now the displayed file name matches the real file name when such a document was loaded, where before the original file name was displayed. Probably such references didn't even work before if the reference spanned more than one sheet, which is a rather rare case for external references. Change-Id: I38035f2e4b3a11c0280457498cf62b02f882d2a1 (cherry picked from commit 56238d58a7da705e4e91604964e6564d819a9196) Reviewed-on: https://gerrit.libreoffice.org/18035 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-13 13:11:25 +0000