summaryrefslogtreecommitdiff
path: root/sc/source/ui/view/spelleng.cxx
diff options
context:
space:
mode:
authorArmin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de>2024-01-15 18:45:03 +0100
committerArmin Le Grand <Armin.Le.Grand@me.com>2024-01-17 01:56:01 +0100
commitb8e393686c4ab6a69b091240065f440eadfff230 (patch)
treead8e6f1291887fc677385e28879175052e309874 /sc/source/ui/view/spelleng.cxx
parent1a637a07a0fb23f4d4bfac69378caff7ee965737 (diff)
ITEM: Remove suspicious extra-Which in ::Put
The ::Put methods at SfxItemSet had an extra WhichID parameter that was not really documented, but I would guess often asked why it exists: An extra WhichID, just called 'nWhich' (which makes things NOT clearer). That is 'strange' since the Item given to be put already internally has a WhichID, so why a 2nd one? If you were really interested and read all that code (no, no comments on that anywhere) you might know that this a kind of 'Target-WhichID' under which the Item shall be put to the ItemSet. Since this is unclear for most people it is even dangerous and explains why so many code places just hand over the WhichID requsted from the Item that already gets handed over. To make it short: I removed that. For the 19 places where this was really needed I added a new method besides ::Put called ::PutAsTargetWhich that takes that extra WhichID (now called TargetWhich) and takes the needed actions. These are quite some because that may be combined with the bPassingOwnership flag, see new SfxItemSet::PutImplAsTargetWhich method. This makes usage of ItemSets/Items less dangerous. It also simplifies and thus makes safer the central helpers implCreateItemEntry/implCleanupItemEntry which have some less cases to handle. Debugged the failing UnitTests showed that there is an incarnate Item != SfxVoidItem that causes problems. I checked for errors in the change, but no luck. Afterr some time I found out that a ::Clone implementation caused the problem: These need to also copy the WichID of the original, but the SfxFrameItem failed to do so. This did not cause problems in the former version because implCreateItemEntry was designed to set a missing/ different WhichID. I corrected that in SfxFrameItem, also removed not needed costructor that caused that. Also added a SAL_WARN and a correction in implCreateItemEntry. I could have added an assert (did so for running local UnitTests), but should be enough. NOTE: When hunting for Items except SfxVoidItem that get crerated using a WhichID '0' i learned that this indeed happens: There are some (5) calls to SfxRequest::SetReturnValue that incarnate an SfxBoolItem with WhichID '0' (ZERO). This is not good and I think about how to change that... Change-Id: I9854a14cdc42d1cc19c7b9df65ce74147d680825 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162124 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Diffstat (limited to 'sc/source/ui/view/spelleng.cxx')
-rw-r--r--sc/source/ui/view/spelleng.cxx2
1 files changed, 1 insertions, 1 deletions
diff --git a/sc/source/ui/view/spelleng.cxx b/sc/source/ui/view/spelleng.cxx
index 0183e1e04f34..7fc859b616fa 100644
--- a/sc/source/ui/view/spelleng.cxx
+++ b/sc/source/ui/view/spelleng.cxx
@@ -143,7 +143,7 @@ bool ScConversionEngineBase::FindNextConversionCell()
else
pNewAttr = new ScPatternAttr(mrDoc.getCellAttributeHelper());
- pNewAttr->GetItemSet().Put(SvxLanguageItem(aLang.nLang, EE_CHAR_LANGUAGE), ATTR_FONT_LANGUAGE);
+ pNewAttr->GetItemSet().Put(SvxLanguageItem(aLang.nLang, ATTR_FONT_LANGUAGE));
mrDoc.SetPattern(aPos, CellAttributeHolder(pNewAttr, true));
}