summaryrefslogtreecommitdiff
path: root/sc
AgeCommit message (Collapse)Author
2023-12-07tdf#158465 - UI: Part 48 - Unify lockdown behavior of Options dialogBalazs Varga
for Calc - Defaults Page. Change-Id: I813469c6e56f0bd148afb17644853116e4ae0398 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160419 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2023-12-07Resave with newer Glade versionBalazs Varga
Change-Id: I252b2a2a51a12463fb2ffc764c2531ac8d5f723c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160418 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2023-12-07tdf#33201 Move Cell position logic inside the functionSahil
Previously to Highlight some cell's row/column, one had to get the current cell cursor position, and pass it to HighlightOverlay(), but now that is not required. Change-Id: I4d08bf1fa84fcbd4820fd166c1d137bd3d950413 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160151 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-07simplify and modernise ScopedBitmapAccessNoel Grandin
(*) Make all of it use a "Scoped" paradigm (*) pass by value, no need to allocate on heap (*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods. (*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places. Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-12-07tdf#158464 - UI: Part 47 - Unify lockdown behavior of Options dialogBalazs Varga
for Calc - General Page. Change-Id: I2ff8edd0fb10a3f388459d842c79b157bc3861f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160407 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2023-12-05Resolves: tdf#158223 Revert "fix" for tdf#156174 and follow-upEike Rathke
... introducing a real fix. commit 94ca402cd1fe2fd9776d08448f7216b7f638e69a CommitDate: Tue Jul 25 15:04:01 2023 +0200 tdf#156174 sc DBData: fix regression of database ranges just cured a symptom by removing a condition that shouldn't had been removed, instead of getting to the real cause of an odd reference update. Shrinking the end of a sheet reference range and thus moving it one before the previously referenced relative position is only possible if the deleted sheet actually touches the referenced range, which here the start value points to and thus checking ref>=start+delta is not necessary and subtracting 1 even harms. This is different from deleting columns or rows where the start value points behind the deleted area of moving the following area. Change-Id: If9ae5dd6f6ae5cd248ad5d999f1aa7577d4ec035 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160374 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2023-12-05sc: show a message dialog if insert cells failHenry Castro
Use case, go to the max row and insert a row. Signed-off-by: Henry Castro <hcastro@collabora.com> Change-Id: I930d7724b9c94e10e9207ec749b7249d2fee0e39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160314 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit eccbe3bb4ed6f0bed4e7fbacfaf50762c93f9464) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160183 Tested-by: Jenkins
2023-12-05[API CHANGE] Drop unused XAxis/YAxis config groupsGabor Kelemen
from Calc grid options. Spotted while researching for tdf#158473 last mention of ther getters was commented out in 2001 by: commit a4e5d2cb47275e91834e41a9d51f1bf11ec409b1 Change-Id: Iffc7b5c4fb50352ad7063fc911039707a20dca4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160169 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-12-04cid#1545597 Using invalid iteratorJulien Nabet
and : cid#1545537 Using invalid iterator cid#1545508 Using invalid iterator cid#1545494 Using invalid iterator cid#1545478 Using invalid iterator cid#1545427 Using invalid iterator cid#1545420 Using invalid iterator cid#1545400 Using invalid iterator cid#1545300 Using invalid iterator cid#1545258 Using invalid iterator cid#1545257 Using invalid iterator cid#1545200 Using invalid iterator cid#1545183 Using invalid iterator Change-Id: Ibf3a41902f34286967195c5c3b22e337a4b06809 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160322 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04sc SetLayoutRTL: Only call PostPaint for current tabAron Budea
...instead of the usual 0-9999, a layout change of the current sheet should have no effect on others. Change-Id: I5a9a2da78daf1fab06da939574c0e8a027533fcd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160254 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 67cdcf1ab2d2977fa79f9ecd7935ad8f3a8b4377) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160181 Tested-by: Jenkins
2023-12-04lok: Notify all tabs in the rangeAron Budea
34d5abf464dfbf4bdc36f6b87e606c84a1f4d99d restricted this to the first tab, but PostPaint(...) is sometimes called with a 0..9999 tab range, even if the change only affected somewhere in between. In addition, restrict range end to the last actual tab in the spreadsheet. Change-Id: I44a7bb351e17bf85b13fedfe2a9f3d76543c4372 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160253 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 4d30910523bccb3b965f254401e6341af2ee8704) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160182 Tested-by: Jenkins
2023-12-04cid#1545810 Using invalid iteratorJulien Nabet
and : cid#1545802 Using invalid iterator cid#1545745 Using invalid iterator cid#1545717 Using invalid iterator cid#1545675 Using invalid iterator cid#1545668 Using invalid iterator cid#1545639 Using invalid iterator cid#1545634 Using invalid iterator cid#1545629 Using invalid iterator cid#1545620 Using invalid iterator cid#1545608 Using invalid iterator cid#1545607 Using invalid iterator cid#1545601 Using invalid iterator Change-Id: I403842175f64a570d7e52fba7c3e03bf21b7d05b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160320 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04cid#1546021 Using invalid iteratorJulien Nabet
and : cid#1545983 Using invalid iterator cid#1545969 Using invalid iterator cid#1545949 Using invalid iterator cid#1545929 Using invalid iterator cid#1545911 Using invalid iterator cid#1545910 Using invalid iterator cid#1545886 Using invalid iterator cid#1545870 Using invalid iterator cid#1545813 Using invalid iterator Change-Id: I2ad10c2a9affd348050a4abe0917a90927a52547 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160317 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04tdf#33201 Checkbox Implementation for Col/row HighlightSahil Gautam
Change-Id: I32aca7128a3f01be9fd5a7150243f8fd4e82f626 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159001 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-04tdf#158483: sc_subsequent_filters_test4: Add unittestXisco Fauli
Change-Id: I1635e5b9ad7a365e97dedaf92cdf436ae1ed814a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160295 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-12-04cid#1546332 Using invalid iteratorJulien Nabet
and : cid#1546327 Using invalid iterator cid#1546289 Using invalid iterator cid#1546284 Using invalid iterator Change-Id: Ia0c8c69433a51fd356930f40f17f50774f244239 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160279 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-01cid#1555476 silence Unchecked return valueCaolán McNamara
Change-Id: I55db6a470a2aca5ebcbace7859236b08bb67e25b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160212 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-01Prefer checked ptr to SdrPageView over uncheckedArmin Le Grand (allotropia)
Change-Id: I1610cb82681e415ba6e4a741ad46e5aa90148989 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160201 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-12-01move the SfxItemPoolCache to sc/Noel Grandin
and rename it to ScItemPoolCache, since its only use is to handle ScPatternAttr objects Change-Id: I68a2dd5f47fcf902f9df552e1a1767d5061d85d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160162 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-30Make ScOutputData::DrawSelectiveObjects compatibleArmin Le Grand (allotropia)
The implementation was not aware of the used functionality in the used call to SdrPageView::DrawLayer: The given OutputDevice is *not* intended to hand over a new render target, it's used to allow the mechanism(s) to *identify* one of multiple possibe registered render targets (which are usually OutputDevice/SystemWindow). It is even the default to call these method(s) with a nullptr which means to repaint all registered OutputDevices/SystemWindows. This is no tooling intended to repaint parts of a View to 'any' OutputDevice. This is not very obvious and there are already other places in the office that do that wrong and never got cleaned-up, therefore also being fallbacks to not just let those cases fail, but at least paint something (and give you a warning). The caveat is that these fallbacks (e.g. in SdrPageView::DrawLayer) have to use temporary SdrPaintWindow/ SdrPageWindow instances to make the paint work. Especially when a temporary SdrPageWindow is used an evtl. existing VC/VOC/OC structure will not be used and with it also not the existing primitive decompositions. I thought about bigger changes in PageView/PaintView/ PageWindow/PaintWindow area to sort that out, but this is - despite being utterly necessary - too expensive for now, keep a note about this needed change for the future. For now I will just use an already (also for this purpose already existing) 'compromize' that will do it for now. Change-Id: I8c7ccee1deb0d69aad1d2145a7ac2039aca685b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160155 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-30cppunit test for notification of note position changes on row/col changesCaolán McNamara
Change-Id: I32ed5cd249400f71903e7aa848ba63d03abbd9b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160139 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-30No kit notification of note position changes on insert/delete rowCaolán McNamara
while there is for insert/delete col. Inserting/Deleting a column will explicitly update comments as part of a bulk operation and block the drawing layer from updating any existing captions before that. A side-effect of this is that the note captions are generated for all comments in the moved cols when this happens. While with a row the drawing layer is allowed update existing caption positions and doesn't generate any new captions. Presumably there's a missed optimization for insert/delete cols to not generate extra captions that didn't exist before the change, but leave that aside for now and add a UpdateNoteCaptions that just notifies of note position changes when rows are inserted/deleted and continue to piggy back on the note caption update for insert/delete cols. Change-Id: I4d76d15aee1de9ea5553e90b2051354bce02b1db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160138 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-29sc: qa: add unit test "testBackColorFilter"Henry Castro
Change-Id: Icdccd6778d1157bb31f38b510a58562a640bdeae Signed-off-by: Henry Castro <hcastro@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159929 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160089 Tested-by: Jenkins
2023-11-29Extended loplugin:ostr: scStephan Bergmann
Change-Id: I2b69249d6e0e35945e37e04ea885bb8ab3e781f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160103 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-29sc: fix back color filter entriesHenry Castro
The function "GetFilterEntries" iterates only that contains cell data value entries, the background color filter feature requires to iterate background color attribute which is not stored in multi type vector cells. Signed-off-by: Henry Castro <hcastro@collabora.com> Change-Id: I372db48d2399f62712f642eefdbfea8885b09f58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159864 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 826eae46095b2184554565bab1792e96964a720f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159905 Tested-by: Jenkins
2023-11-28cid#1555974 silence Unchecked return valueCaolán McNamara
Change-Id: Id4d208013d9e25b6c14387963144f38fdcd992f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160016 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-28Always send theme-change in kit-mode even if the global theme is the sameCaolán McNamara
Kit explicitly ignores changes to the global color scheme, except for the current ViewShell, so an attempted change to the same global color scheme when the now current ViewShell ignored the last change requires re-sending the change. In which case individual shells will have to decide if this color-scheme change is a change from their perspective to avoid unnecessary invalidations. Add ConfigurationHints::OnlyCurrentDocumentColorScheme as the hint that only the document color scheme has changed, so individual shells can see if their document color scheme is different to this new color scheme and not invalidate if unnecessary. So dark/light mode changes work properly without reintroducing unwanted invalidations. Change-Id: I5ebb4878694ceb6b9afe26286a30da06ea6ff3ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160002 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-28ScViewOptions::operator== doesn't compare sColorSchemeNameCaolán McNamara
Change-Id: I21e6630deb9a5329092c88651e4ba0a3715ce616 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159997 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-27tdf#158302 fix build against system-libxml-2.12Miklos Vajna
Seen in a fedora:40 container, using --with-system-libcmis, --with-system-liblangtag and --with-system-xmlsec. Change-Id: I9d748d3dc0b70dbfdfcb6b99c9ce8440bda6f326 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159980 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-27tdf#33201 Change default HighlightOverlay colorSahil
Change-Id: I734b780808da35cdc58c55ede914f87e96fbdd99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159778 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2023-11-26Fix typoAndrea Gelmini
Change-Id: Ie6778eed60a068c15e57799b7c4e766c2890bf35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159958 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-24tdf#158294 HTML simple format also added to paste special toolboxOliver Specht
adds the format HTML simple to the paste special toolbox controller in impress and with draw text selection in calc and writer Change-Id: Ibdca5d3cd5ab4640320cff3b03b30f6575e8fec8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159791 Tested-by: Jenkins Tested-by: Gabor Kelemen <kelemeng@ubuntu.com> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-11-24use more concrete UNO in scNoel Grandin
Change-Id: Id486b94464bfa49ed471bcb825acee7bddeacb8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159873 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-24loplugin:fieldcast in ScXMLImportNoel Grandin
Change-Id: I0820427504d0cb9e14b54bb92a2e383bf0137121 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159872 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-24use more concrete UNO in scNoel Grandin
Change-Id: I20f0200a4ed74b32b67b740e0084dae9620c2912 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159871 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-24loplugin:fieldcast in oox::xls::PivotTableNoel Grandin
Change-Id: Ie50626b2e24bba2ee67827afcdf42c1c0ed2c9d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159870 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-23tdf#158252 sc: Enable text wrapping when inputting line breaks in cellofftkp
In Excel, when typing new lines in a cell or pasting text with new lines and then clicking out of the cell, wrap text is enabled, which actually shows the contents on the new line instead of on the same line Change-Id: I113aceab33380a5deb536f57969c3fc90825146b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159758 Tested-by: Paris Oplopoios <parisoplop@gmail.com> Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
2023-11-22tdf#125580: sc_subsequent_filters_test4: Add unittestXisco Fauli
Change-Id: Ia7be1c4dd1f4d748bb70fdc43c52825b4dade1b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159836 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-11-22tdf#127498: sc_datetime_functions: Add unittestXisco Fauli
it fails with Sheet2.A9 '=TIMEVALUE(K9)' result: 0.354166666664241, expected: 0.354166666666667 without the fix in place Change-Id: I4e6faff1b7eb1913ca668ef11b489076e793adc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159820 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-11-22tdf#148000 impress: improve fontwork text placement.Attila Szűcs
Improved the calculation of positions of text characters for multi-line texts. The previous version only fitted the text to the basic outline (curve), and then scale them to the appropriate text line. This means that the text will be wider or shorter, depending on the shape of the curve, and which line it is on Now it calculates a curve for each paragraph and fits text on it. Text will be approximately the same width on each line. Except if the text is wider as the curve. Because then it shrinks the text to fit on the curve. (this can only happens on inner curves) Reused the same compat flag that was used in bug148000, now it serves as a Powerpoint compatible mode for FontWork, so no need to create new compat flag every time FontWork has improve. That means that the Fontwork in old documents has remains the same Refactored horizontal/vertical alignment, but had to keep the old hacks as well. Note: if there are too many lines of text, and the vertical alignment causes internal curves, then curves can shrink to 0 length (center point of a circle) or even to negative length, These cases are impossible to display normally, so it will be glitchy similar to how it was before this patch. MS PowerPoint avoid these cases by not allowing vertical alignments that would result internal (smaller) curves. Added unittest to check legacy-odb / new-odp / pptx file. It change the display of fontwork, so in some cases it may feel like a regression. Change-Id: Iac2d9bc751bbc2b6f747c33958f969cb3543fae5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159776 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-21Cleanup some ScPatternAttr specific stuffArmin Le Grand (allotropia)
Removed some special stuff in the ItemSet/Item tooling regarding ScPatternAttr. There are still quite a view (grep for isExceptionalSCItem), but all these are identified and isolated. Only for that Item (of over 500) are these exceptions, so that raelly does not fit into the Item schemata in any way. Not even the pool default of ScPatternAttr is without trouble. It is the only and last Item that needs to be 'pooled' in the sense to avoid copies on any price. That is OK, but should not be done in the ItemSet schemata. In short: It should not be an Item at all. It should be changed and renamed to something describing it's role (CellAttributes..?) and get helped/assisted by something called CellAttributeHelper at SC's model or Pool. It should not even be derived from SetItem, it could just contain an shared_ptr of SfxItemSet (allows more and better optimizations - think about Clone() and op==). In parallel, all these hacks in the ItemSet/Item stuff could be removed, making that faster and easier. Also quite some usages of DirectPutItemInPool could be cleaned-up, this only exists since there *is* no defined place to hold that data (coud be CellAttributeHelper in the future). Putting Items directly to the pool (and in most cases never remove them again) is just nonsense and another hint that all this does not fit to the Item/ItemSet schema at all. This is now - after hard isolation of problems and have all working - doable. It may be one of the next things to do, but there are other candidates, too. Doing this would mostly only help SC... Found another hack that uses DirectPutItemInPool and *never* removes any Item again, see comments framelinkarray.cxx And another one: PoolItemTest::testPool() explicitely tests DirectPutItemInPool stuff - which makes no sense long-term, but for now keep it and make it work by marking the slots used as _bNeedsPoolRegistration == true Have now overhauled the framelinkarray stuff to work without DirectPutItemInPool and Cell not being a SfxPoolItem. That will be much less complex and use much less calls/checks. Since this is the data structure created for every calc repaint that should get faster, too. Also for now and memory loss security I added code to DirectPutItemInPool to behave the same as with the unchanged implCreateItemEntry: register Items so that the garbage collection still is used. This will/can be removed when all usages of DirectPutItemInPool is cleaned up. Directly registering in DirectPutItemInPoolImpl is more tricky than thought, but a good thing to do. Looking at that I saw that tryRegisterSfxPoolItem is not used anymore, so rearranged some stuff. Change-Id: If07762b0a25e2739027f81872441772dc82a25d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159685 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-20lok: async calc merge-cells popup dialog.Michael Meeks
Change-Id: I6f7d1e8de4ac36f546706f7702157cc7e49c80b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159581 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2023-11-20pass by ref, not pointer, in ScViewFunc::ApplyAttributesNoel Grandin
since we always de-ref the input params Change-Id: I222e58547b37186841c6b435adcea73f4d43b55c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159733 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-20use the cheaper variant of SfxItemPool::areSame where possibleNoel Grandin
Change-Id: I10a357293ef176fb8aba7a683cac9a73ac3ea897 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159684 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-19Extended loplugin:ostr: scStephan Bergmann
Change-Id: I44536a13f4c31558671c1166d06b7f6216456641 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159680 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19Fix typoAndrea Gelmini
Change-Id: I4a1f624793c0bf2e97ee862b4599aa9c8fb9f9d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159692 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-19tdf#33201 Make Row/column highlight usableSahil Gautam
Row/column highlight shouldn't be updated using ScGridWindow::DrawContent because it would call for highlight refresh even when typing in a cell, leading to the text being hidden under the highlight. Change-Id: Ic7cc71bc94629c71e6efdf677b7f34d6c4d0cc93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159636 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-11-19c++20: use std::erase(_if) instead of std::remove(_if)+erase (part 8)Julien Nabet
Change-Id: Ia726fbbfd3f08eb4bb5c7ccaf10d65fe01ca6585 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159639 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-19Fix performance regression with ScPatternAttr/SCArmin Le Grand (allotropia)
Due to the paradigm item change the test make CppunitTest_sc_tablesheetobj with CPPUNIT_TEST_NAME sc_apitest::ScTableSheetObj::testSheetCellRangeProperties got much slower. Unfortunately it did not break, so got unnoted. I took a look now. First I intended to add some hashing in an std::unordered_set using that hash values at ScPatternAttr, but that is not even possible due to other data in that item that needs to be compared. I had the impression that it was 'somehow' hashed before, but after debugging the version before that change I noted that also the list of existing items was linearly compared to the new entry, using the operator==. Thus the problem was not due to not hashing, but due to the ScPatternAttr::operator==. That uses the hash (not changed), but no longer finds equal entries. This is because the hash code is made up from the SfxPoolItemPtrs in the SfxItemSet, so when all are equal we can be sure the SfxItemSet content is equal. To use this the other way around is *not* correct: Even with not all ptrs equal the SfxItemSets can still be equal, simply by one SfxItemSet using another, but identical incarnation of an item. Thuis means that ScPatternAttr::operator== does not detect all cases of equality. This worked in most cases before since most items were 'pooled' and thus much effort was used to ensure their uniqueness, but even before the paradigm item change an item type could be flagged as non-poolable. In that case, this already could fail but with no too bad consequences (just one more copy of an ScPatternAttr would stay). So I fixed that mainly in adapting and optimizing ScPatternAttr::operator==. The results are (same machine, same compiler, dbg version, metioned test): Version before item paradigm change: user 0m50,778s Version after item paradigm change: user 20m13,944s Version with memcmp: user 0m48,845s Version with hash: user 0m48,710s Since that hash does nothing else than to buffer the comparison of those item pointers I just tried to use memcmp instead, as is already used in other places (same file, ScPatternAttr::FastEqualPatternSets, also SfxItemSet::operator==). As can be seen above it makes practically no difference (memcomp even slightly faster). Since that hash is only used in ScPatternAttr::operator== and is same speed (memcomp linearly compares 56 SfxPoolItem ptrs) I decided to remove it. It needs quite some spaces to be reset and re-calculated which are not needed anymore. The calculation is based on dividing the number of items by 4, so we are good with 56, but if someone has/ will adapt the items used by ScPatternAttr it is easy to forget to adapt this, and not easy to change the alghorithm when it's not a multiple of 4. I also optimized/overhauled SfxItemSet::operator== (or better: the SfxItemSet::Equals used by it). It is now better readable, too. I also adapted ScAttrArray::AddCondFormat to not always incarnate/ delete ScPatternAttr instances, only when needed. This also helps a bit and could be done in more places. All in all it is really necessary to cleanup SC's usage of ScPatternAttr - there are quite some possibilities to make that cleaner and faster. In principle it's a huge 'compromize' to use item functionailty to have a possibly 'cheap' maximum shared SfxItemSet at a Cell. Decided to make SfxItemSet::operator== even faster for the case of unequal ranges by iterating over ranges of local SfxItemSet and incremented offset. Still accesses to 2nd SfxItemSet will be the expensive ones using the iterated WhichID. Added two more things to SfxItemSet::operator==: We can return early when both have no items set. For the unequal-ranges compare I added an early-exit when Count() items were compared. Looked at the errors that indeed do trigger the assert in ScPatternAttr::operator== and hint to incarnations of ScPatternAttr that do not use the needed range ATTR_PATTERN_START, ATTR_PATTERN_END. Hunted down to come from ScViewFunc::ApplyAttributes and there from some Dialogs, so seems some SC dialogs do not work with the correct range schema for that item. I tried code in ScViewFunc::ApplyAttributes to fix it, that works. I also tried to hunt that down to the Dialogs that use the wrong schema (TotalCount @SfxItemSet is 61 BTW). While it would be possible to do so, it's no guarentee to have this fixed. Thus I looked at ScPatternAttr::ScPatternAttr and added correciton code when one with the wrong range schema gets created, this is luckily not often needed and transfers the existing items with low costs. Maybe we should add a warning there if used, so at least new implementations of stuff or old ones (the Dialogs) can be corrected? Change-Id: I31da73ae30786bd6c5a08a5e3b7df8fe279af261 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159592 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-18Remove useless using + once use of replace pair by std::pairJulien Nabet
Change-Id: Id283ac7909f19dabb98886caa1f2960d9098ddbe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159628 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
generated by cgit (git 2.34.1) at 2025-01-24 23:54:41 +0000