/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ /* * This file is part of the LibreOffice project. * * This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. * * This file incorporates work covered by the following license notice: * * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed * with this work for additional information regarding copyright * ownership. The ASF licenses this file to you under the Apache * License, Version 2.0 (the "License"); you may not use this file * except in compliance with the License. You may obtain a copy of * the License at http://www.apache.org/licenses/LICENSE-2.0 . */ #include "../source/implementationregistration/mergekeys.cxx" /* vim:set shiftwidth=4 softtabstop=4 expandtab: */ LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/svx/source/sidebar/paragraph/ParaLineSpacingControl.cxx
AgeCommit message (Collapse)Author
2024-05-11loplugin:ostr in svxNoel Grandin
Change-Id: Ia765a03e033acb82e367873380d289587ea87d6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167449 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-03-21ITEM: Remove InvalidateAllItems()Armin Le Grand (allotropia)
I checked if this is used, but it can be replaced using Clear() -> all. This prevents that the whole array of Items in an ItemSet gets set to INVALID_POOL_ITEM. I also checked if INVALID_POOL_ITEM/IsInvalidItem is needed at all representing SfxItemState::DONTCARE but it is and still will need to be set for individual Items. At last checked if SfxItemState::UNKNOWN and ::DISABLED really need to be separate states, but indeed there are some rare cases that need that. To make things more consistent I also renamed SfxItemState::DONTCARE to SfxItemState::INVALID to better match Set/IsInvalid calls at ItemSet. The build showed a missing UT and led to a problem due to the hand-made ItemSet-like SearchAttrItemList. The state 'invalid' seems to be used as 'unused' marker. It should be changed to use SfxPoolItemHolder and not need that. For now, set by using an own loop to set to that state. Change-Id: Ifc51aad60570569a1e37d3084a5e307eed47d06c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165035 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-12-30tdf#146619 Recheck svx/ with IWYUGabor Kelemen
Change-Id: I99650b50587294c20b1e92270e541140d9ec9cae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161240 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-21Remove DeleteItemOnIdlexArmin Le Grand (allotropia)
There are some CrashReports in 7.6 which have DeleteItemOnIdle on the stack, but there is nothing reproducable. So I took a look... I first thought it's a MCGR regression, due to classes on the stack. But the Item involved is just random, can happen with any Item. Then I thought it may have to do with ITEM refactorings, but it happens with DeleteItemOnIdle involved, so also not the case. I already saw DeleteItemOnIdle when doing these and qualified as 'hack' in the way. already It is only on Windows and DeleteItemOnIdle is involved. This again (took a deeper look now) is an old hack to keep an SfxPoolItem 'alive' for some 'time'. For that, it triggers an async reschedule which then deletes the Item when being called. If the Item will be used after that is pure coincidence - seems to work in most cases. It seems as if for Windows the timing slightly changed for some scenarios, so a reschedule is too early. This can happen with this hack anytime. DeleteItemOnIdle is used in scenarios where SfxPoolItem* is e.g. returned, but is *not* anchored, so e.g. not member of an SfxItemSet. Or in short: Lifetime is not safe. DeleteItemOnIdle exists since 1st import, but was changed to AsyncEvent ca. 4 months ago (see 57145acf9ec47c23e307b7a5c0029d21d937cc35), so that may have caused it. It is possible that these errors happen on Windows since then. Before something more complicated was used to delete it late, but surely also not really safe. Due to ITEM refactor I have the knowledge/tooling to solve this. It will not be a 1-5 lines fix, but it is a hack and in the way for further ITEM refactor anyways. What we have nowadays is a SfxPoolItemHolder -> it's like an SfxItemSet for a single Item. It safely holds/ controls the lifetime of an SfxPoolItem. It is already used in quite some places. It helps to solve many hacks, also the ones putting Items directly to the Pool - due to there never was an alternative for that. In principle the ItemPool/ItemSet/Item paradigm was never complete without SfxPoolItemHolder. Thus I started to fix that (and remove that hack for good, sooo many changes over the years, sigh), but as said is not straightforward. Will have to change retvals of involved stuff to SfxPoolItemHolder - it's just two pointers and designed to be copied (one is a Pool, needed to cleanup when destructing). CopyConstruct/destroy just counts the RefCnt up/down, so cheap. 1st version compiling, let's check on gerrit... Corrected one error in QueryState for securitypage, also added some security features/asserts. Change-Id: Ida49fd35ca88ead84b11d93e18b978cb9e395090 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161083 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-07-23tdf#154038 tdf#83618 fix wrong line spacing valueJim Raykowski
Impress and Writer seem to require different MapUnit values for fixed line spacing metric values to be correctly calculated. This patch initially sets the MapUnit unit value to Map100thMM, which is what it was before commit 849b837d1a3b185a8dd893a8f6eaed53605bcab1, which works for Impress. For Writer, the value is set to MapTwip. Change-Id: I49e9b80aa4d3fbda1f19101903d2a4459089024c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154665 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com>