Both are derived from SfxSetItem which means they contain
a SfxItemSet themselves. That leads to problems since at
their construction time a SfxItemPool has to be known and
it *should* not be different to the one of the ItemSet
that Item gets added later - that leads to the 2nd class
of problems.
In the long therm we should get rid of all SfxSetItems.
This change simplifies already some stuff, including that
the standard Items for DrawObjects reduces by two (and
more due to containing a whole ItemSet) and e.g. the
problem that these Items had to be converted to hard
attributes in the done fixes for copy/pasting Slides.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I8b1c6cabdaa43ed6062811b5508ab3dece47a755
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6795
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e67458a9b769fe7a3a7ee0739ed6d5c46dbc0692)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211734
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Replace memcpy() with std::copy_n() to improve type safety by
eliminating manual sizeof() calculations. This is the single change for
the EasyHack as requested in the review.
Change-Id: Ib2d0f84186a126d6cc1a8a1fa296e418853d13ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204347
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
As Eike indicated in https://bugs.documentfoundation.org/show_bug.cgi?id=146404#c4
COLOR format codes are preserved in ods/fods format.
The pb was the missing map back.
Indeed, we had the mapping for [COLOR<something>] => Color value (eg: "ffaa16")
but not the reverse mapping Color value => [COLOR<something>]
Eike had provided the right code pointer in xmlnumfi.cxx.
First, I thought using PaletteManager but this one is in svx and svx shouldn't be used in xmloff
(dependency pb).
Then I used ChatGpt (GPT-5.6 Luna) and it pointed the right process.
It just consisted to use a similar callback system (DECL_LINK, IMPL_LINK, LINK) of GetUserDefinedColor.
In addition, by testing all this, I noticed that maList in XColorList::GetIndexOfColor was empty.
So I added the Load call in case mbListDirty is true.
Change-Id: I0ef6b5901f2e4c757e88994412dbf79a13100ffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210518
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
The color name is stored in the language the format was parsed in, while
GetMappedFormatstring matched it against the keyword table the scanner holds
at export time. Those differ in a document holding formats of several
languages, and the color was then left out of the exported format - German
being the only language with localized color names. Identify the color by its
value instead, against the standard color table the color keywords are
aligned with; that table is static, so the value does not depend on which
formatter parsed the format.
This surfaced as testLocalePrefix in CppunitTest_sc_subsequent_export_test4
failing in a CODA-W build with
- Expected: #,##0.00\ [$€-407];[RED]\-#,##0.00\ [$€]
- Actual : #,##0.00\ [$€-407];\-#,##0.00\ [$€]
where the German format's name is not normalized because
GetFormatStringForExcel skips that step with the Kit active, see commit
0a5026b367 ("lok: save correct number format in
multi-lang session", 2024-04-26).
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I9874185a3204c8e6aac19532b4b446895807feeb
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8063
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 967df3c828dbaba1d5e1451fcf43b2d57d404c67)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209260
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In commit 93aa742ba3 which is
20 years ago 'cl' did a big change to get to SfxUndoManager
which is a needed abstraction for the formally Svx-based
Undo/Redo stuff.
Unfortunately SdrModel::SetUndoComment was *not* supported
and this was expressed as just doing a
OSL_FAIL("svx::SdrModel::SetUndoComment(), method not supported with application undo manager!" );
in SdrModel::SetUndoComment when SfxUndoManager was used.
But SetUndoComment *is* used in nine cases in
svdraw/svdedtv2.cxx. All of these execute some action and
create Undos for it. All nine Undos were without any Undo
text since then - over 20 years...
I stumbled over that when adding needed Diagram stuff to
UnGroupMarked().
I fix this with this commit. Creating that fix showed me
why 'cl' intentionally did not support that, but just
abandoning functionality is not a good choice.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Idde2fcecc85a9eee39b62d38ed7d71a8cfbd3288
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2486
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 5adf090261d705123074a0fa1c46119b2bf44bf3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206022
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Add LockFileCommon::FormatDateTime() to parse the fixed-format lock
file time string (DD.MM.YYYY HH:MM) and reformat it using the user's
configured locale setting
Add unit tests for LockFileCommon::FormatDateTime()
- testFormatDateTimeShortInput()
- testFormatDateTimeLocaleOutput()
Change-Id: I77c94dc2a21d9bec6cf5e2584556cd89f216c40d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204683
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Replace a few index loops with range-based iteration where the counter
was only used for element access: index algorithm lookup, UTF-16 OLE
string streaming, and scanning DDE connections for a matching handle.
Verification: make svtools sfx2
Change-Id: I5678af4bdab855d7ce60bdccc46f608cee56c4e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204657
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
The Organizer tab of the style dialog now shows interactive "chips"
for each property that differs from the parent style. Each chip
displays the property name and value, and includes an X button to
reset that property back to parent inheritance. All properties
are shown full text, no ellipsis.
Properties are grouped by tab page (Font, Font effects, etc.)
and displayed in a scrollable area. A View/Edit toggle lets the
user switch between the traditional description text and the
interactive chip view.
Implementation summary:
- New PropertyChip and PropertyCategoryRow widgets (sfx2) with
corresponding .ui files for the chip layout.
- SfxStyleSheetBase::GetItemPresentation() virtual method returns
per-property presentation strings, overridden in SwDocStyleSheet
and ScStyleSheet for module-specific attributes.
- SfxItemSet access tracker mechanism to automatically map WhichIds
to their owning tab pages via BuildWhichToTabMap().
- SfxTabDialogController::InvalidateItem() propagates chip resets
to the output set and affected tab pages.
- SwDocStyleSheet::ResetItems() uses SwDoc::ResetAttrAtFormat() to
ensure proper undo support in Writer.
- SfxStyleDialogController::Ok() clears invalidated items from the
style's item set on dialog confirmation.
- SvxAsianTabPage now calls SetExchangeSupport() and implements
DeactivatePage() so its items are properly tracked.
- Access tracker ignore guards in SvxCharBasePage::SetPrevFontWidthScale
and SvxTransparenceTabPage::InitPreview to avoid false positives
from preview-only item access.
Includes a UITest for Writer (sw/qa/uitest/ui/fmtui/tdf89826.py)
that creates a child style, modifies a property, removes it via
chip, and verifies inheritance is restored including undo.
A Calc UITest is not included because the style edit dialog in Calc
is opened asynchronously (ScTabViewShell::ExecuteStyleEdit) and the
UITest framework's execute_dialog_through_command cannot capture it.
The Calc functionality has been verified manually. A Calc UITest can
be added once the framework supports async style dialogs.
Change-Id: Ia764405798c212fe5340bba254f2ff6ac62365f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199318
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Use the correct term. E.g., Unicode charset has different encodings
like UTF-8 and UTF-16, and we mean encoding here.
Change-Id: I65e90b31cda6e39fdb1584b492e6e0b9821865a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200285
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...by completely getting rid of the code exhibiting UB and the helpless
workaround from 2b27652d2d "tdf#167892 fix hang
formatting very small number on windows".
TODO: It is unclear to me whether using saturated values here is any better
than using whatever random values came out of the original code that exhibited
UB. The whole algorithm probably needs to be replaced with something that
actually works.
(This was now reported with 4368272648
"tdf#167892: svl_qa_cppunit: Add test" as
> /svl/source/numbers/zformat.cxx:2886:52: runtime error: 1e+19 is outside the range of representable values of type 'long'
> #0 0x7f3f6da013eb in SvNumberformat::ImpGetFractionElements(double&, unsigned short, double&, long&, long&) const /svl/source/numbers/zformat.cxx:2886:52
> #1 0x7f3f6d9f84ee in SvNumberformat::ImpGetFractionOutput(double, unsigned short, bool, NativeNumberWrapper const&, rtl::OUStringBuffer&) const /svl/source/numbers/zformat.cxx:2961:5
> #2 0x7f3f6d9e472a in SvNumberformat::GetOutputString(double, rtl::OUString&, Color const**, NativeNumberWrapper const&, SvNFLanguageData const&, bool) const /svl/source/numbers/zformat.cxx:2676:21
> #3 0x7f3f6d8c37bc in SvNFEngine::GetPreviewString(SvNFLanguageData&, SvNFFormatData const&, NativeNumberWrapper const&, SvNFEngine::Accessor const&, rtl::OUString const&, double, rtl::OUString&, Color const**, o3tl::strong_int<unsigned short, LanguageTypeTag>, bool) /svl/source/numbers/zforlist.cxx:2147:20
> #4 0x7f3f6d8c3ddb in SvNumberFormatter::GetPreviewString(rtl::OUString const&, double, rtl::OUString&, Color const**, o3tl::strong_int<unsigned short, LanguageTypeTag>, bool) /svl/source/numbers/zforlist.cxx:2165:12
> #5 0x7f3f6ef90fd3 in (anonymous namespace)::Test::checkPreviewString(SvNumberFormatter&, rtl::OUString const&, double, o3tl::strong_int<unsigned short, LanguageTypeTag>, rtl::OUString const&) /svl/qa/unit/svl.cxx:462:21
> #6 0x7f3f6ef67f13 in (anonymous namespace)::Test::testUserDefinedNumberFormats() /svl/qa/unit/svl.cxx:1443:9
<https://ci.libreoffice.org/job/lo_ubsan/3801/>.)
Change-Id: Iff449629ee309f9513af02da9dfdf2505d6fe725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198278
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Workaround undefined behaviour where llvm/gcc produces different
code from MSVC, resulting in oscillation in this algorithm.
regression from
commit 44d17f8feca372acd41142d1b607d3360282bf30
Author: Eike Rathke <erack@redhat.com>
Date: Tue Oct 13 21:41:45 2020 +0200
Resolves: tdf#137453 Implicit conversion from sal_uInt64 to sal_Int32 is bad..
Change-Id: I486e8caabcbf582cf94b47547efc89d1b206503e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198163
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Armin Le Grand (collabora)