The events may be processed after the shell has been destroyed. This is
happening reliably after commit e2bfc34d14
(Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable,
2024-03-11) when controlling LibreOffice from external Java scripts; but
obviously, it could happen before as well.
Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase.
Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Driving forward the Item reworks I now take the
ItemPool in focus: It now does not hold any items
anymore and should be renamed to something like
ItemInfoProvider/ItemHelper, since it's main purpose
is to provide the Defaults for the Item functionality.
There is that SfxItemInfo, only a struct and bundling
SlotID and ItemFlags. There are also the DefaultItems,
just handled as ptrs in an array. It is/was always
error-prone to keep these in sync. Remember that it's
also necessary for the order to not only being sorted
but being increments of one with no gaps allowed in
the WhichIDs to which the Items are bound.
I now bundled that to a new class ItemInfo that joins
WhichID, SlotID, ItemFlags and the default Item. This
is a pure virtual base class, it comes in three
derivations:
(1) ItemInfoStatic:
This is supposed to be global static and hosts the
Item in a std::unique_ptr to ensure cleanup. It is
designed to be constructed once during runtime and
being shared globally. It allows the ItemPtr to be
nullptr to mark as non-static (if initial static is
not possible for some reason) but still offers the
needed data. Most cases (95%+) are of that case.
The contained Item is owned by that instance. The
flag isStaticDefault() is set at the Item.
(2) ItemInfoDynamic:
This is supposed to be used for cases where the Item
cannot be static: Mainly for SfxSetItem (that needs
a Pool itself in the contained SfxItemSet, so lifetime
is bound to that Pool), but other cases showed up in
the transition. These instances live while the Pool
lives and get destructed when the Pool goes down.
Also uses std::unique_ptr for the Item instance for
as much automated cleanup as possible, the contained
Item is owned by that instance, the instance by the
Pool. The flag isDynamicDefault() is set at the Item.
(3) ItemInfoUser:
This is used for UserDefaults that can be set for
every ItemInfo entry to 'overshadow' the default
from the 'outside'. It uses a regular Item and
the central access methods implCreateItemEntry/
implCleanupItemEntry to manage the Item instance,
thus works like a SfxPoolItemHolder. The Item
instance can be globally shared and re-used even
when the Pool goes down. Instances belong to the
Pool and are cleaned up when the Pool goes down.
This Item does not need any further flag to be
set.
The ItemInfos are organized using a class
called ItemInfoPackage:
This bundles groups of ItemInfoStatic to
functional instances. There are derivations/
implementations of this e.g. for Writer ItemPool
bundling all the needed defaults for Writer,
similar for draw/impress, Calc and other usages.
These ItemInfoPackage can be 'registered' at an
ItemPool using it's method registerItemInfoPackage.
This does all the needed stuff to setup that
group of ItemInfos at the Pool (It even sets
internal vars First/LastWhich, that info can just
be derived from the buildup ItemInfo Ptrs).
The ItemInfoPackage has methods 'size()' and
'getItemInfo(index) to allow looping over it
and deliver the infos the Pool needs. The
(forced, pure virtual) overloads of getItemInfo
in the specific implementations check for the
ItemPtr being nullptr and create a exclusive
incarnation of ItemInfoDynamic for the Pool if
needed, returning that. The Pool owns the
ItemInfoDynamic incarnations and uses the
ItemInfoStatic directly. On shutdown it cleans
up the ItemInfoDynamic as needed.
The ItemInfoUser is used by the Pool when a
UserDefault is set/used: for SetUserDefaultItem,
GetUserDefaultItem, ResetUserDefaultItem. It
is not held in a 2nd list, but directly in the
list of ItemInfo'ptrs: To keep track of this
an unordered_map is used that helds the original
ItemInfo associated with the WhichID. That way
no two lookups (as before) are needed to get the
current Pool's default for any WhichID.
The derivations of ItemInfoPackage are
encapsulated and just allow access to an
ItemInfoPackage& with a single method as
return value. All use a static local instance
of a std::array<ItemInfoStatic, FIXED_SIZE>
which constructs all ItemInfoStatic and the
static Item instances - if already possible.
Sometimes it is necessary to overload the
constructor to set some static instances
for Items later than the lib init. These are
also just marked with nullptr as Item instance.
Some need to overload getItemInfo to complete
instances of ItemInfoStatic, if needed, or
create and deliver instances of ItemInfoDynamic.
The registerItemInfoPackage also offers a
optional lambda callback: there were two cases
where local data from the Pool was needed to
incarnate the item - just add that to the
call to registerItemInfoPackage if needed,
see examples in the adapted code.
For the re-use of Items this means that now
in SfxItemSet/SfxPoolItemHolder *true* static
Items can and will be used without RefCount
directly and globally. This is also the case
for dynamic Items, with the exception of
differing Pools for SfxSetItems which cannot
be done.
Future:
That design is already prepared to allow
solving that Pool-chaining problem: currently
there are master/sub-pools and all accesses
have to traverse that structure before even
doing anything.
For the future the idea is more to 'compose'
a Pool by registering ItemInfoPackages, e.g.
for Writer pool you may start with SfxItemPool,
register the writer-specific ItemInfoPackage,
then the one for DrawingLayer (if needed) and
the one for EditEngine.
It should also be possible to get to smaller
granularities of that packages. Ideas for
new ones will emerge. We might also think
about composing Pools which can e.g. run Writer
and Chart, so allowing to use Chart *without*
OLE stuff in Writer - just ideas...
More changes:
- Adapted all stuff, cleaned up old stuff/
definitions
- Removed FreezeIdRanges, that can be done
once per Pool on-demand (and cannot be
forgotten to be called)
- Merged XOutdevItemPool with SdrItemPool
and offered a ItemInfoPackage which joins
both needed sets of Items
- All the cleanup hassle with Pools and
defaults cleaned up
- Adapted all access methods of the pool
to use that new stuff. Pool chaining
currently stays, but I use a central
method 'getTargetPool' instead of
recursive calling to get the correct
Pool for the action
Change-Id: I2b8d3d4c3cc80b1d0d0b3c0f4bd90d7656b4bab7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163157
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This patch adds the "toggle comment" functionality to the Basic IDE.
The shortcut Ctrl + Alt + C is used to execute it.
It works similarly to other code editors such as Kate and VSCode.
Change-Id: Ifdae42b3729cc909baf87c729fe8c3cdf6428184
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162005
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Prior to this patch, if a library had multiple modules and the color scheme was changed (via View - Color Scheme), the line hightlight color would only update for the current module and remain unchanged for the other modules in the same library.
Change-Id: Idda78c07d02534dfedcd927c37116a2617500ebc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162818
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
As requested by the user in the ticket, the Line Numering and Breakpoint windows should be on the left side, even on RTL locales.
Change-Id: Iad2ba8efa0a23a13cf88c2fa277c4eed45002aae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162540
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This patch implements support for highlighting the selected line in the code editor, similar to what Kate, VSCode, etc do.
If the cursor is positioned in a single line and nothing is selected, then a highlight color is applied to the line. The line number window also highlights the selected line.
Change-Id: I2047d79500cd783b122b6752bb00996de0a7c702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161861
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
This patch remembers the visibility of the Object Catalog, Watched Expressions and Stack Window in the Basic IDE.
Change-Id: I2fea038ffc56af45cd6570feeb14ab84307f8cef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161852
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
This patch implements a color scheme selector for the Basic IDE. With this new feature the user can either:
1) Choose to stick with "Application Colors", meaning that the colors defined in "Tools - Options - Application Colors" are applied.
2) Use one of the available color schemes in the dialog
To access the color scheme dialog, go to View - Color Scheme.
A color schema was defined in the "BasicIDE.xcs" file and six color schemes were defined in "BasicIDE.xcu" to be shipped with LibreOffice.
This way, it is possible to install more color schemes via extensions;
Change-Id: I5d382d19f982d02ba3c0fda5d1596aed2c38f13c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155928
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
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
57145acf9e), 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>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
First comment was last updated with USHORT -> sal_uInt16 in
a2242be9c3 but with the newer commit
68ec95b3f8 there is no remaining sal_uInt16
left, and thus the comment is no longer relevant.
Second comment was added in 1fac87f847,
but with changes in 444c242c51 it is no
longer relevant.
Third comment was also last updated with USHORT -> sal_uInt16 in
a2242be9c3 but with the newer commit
444c242c51 it is no longer relevant.
Change-Id: I9ed383f15a5b403740c0b8bcdd153d04bb1a2b0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158111
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Instead of returning ErrCode class everywhere, return a new
class ErrrCodeMsg, which combines an ErrCode with the other
parameters that are used to control the error reporting.
I do not change everything that uses ErrCode here, I started
from SfxBaseController/SfxMedium and worked outwards.
This change serves two purposes
(1) Replace the extremely whacky ErrorInfo mechanism we were
using to smuggle information into the error handler reporting
mechanism with a very straightforward approach of just combining it
into the error class.
(2) Allow us to capture the source location that produced the error,
which makes debugging the source of a problem soooo much easier.
Change-Id: I978b8f00c9851b41a216c7ebdef2ef94251d5519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157440
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
changes traditional for to ranged based for in localizationmgr.cxx
goal: better readability for programmers
Change-Id: Ifde48037b27a794a9cdc3b1183f825651896cafb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148127
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
so the form combo box can be added without exception, likely either a problem
from:
commit 9cff030fa1
Date: Mon Dec 5 09:56:17 2011 +0000
add some form control support for basic dialogs
or:
commit c0d6bc75b2
Date: Fri Jun 5 14:52:44 2015 +0100
Resolves: tdf#90361 CellValueBinding/CellRangeListSource need WithArguments
Change-Id: I80e670840195a6725a9fdedc024f9763ad12ffe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150599
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Mike Kaganski