Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I2aa09655c207d3647650b5e38011a600bd221699
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165777
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
In commit e2bfc34d146806a8f96be0cd2323d716f12cba4e (Reimplement
OleComponentNative_Impl to use IGlobalInterfaceTable, 2024-03-11),
I added the assert in a false assumption that RunObject may only
be called once. Indeed, this is not so. Thus just make sure to not
try to register it second time.
Change-Id: I36fc4f3939bd0061e462659749bba8e4bd3075ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165299
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I6d0b5fa249cb466230183e11fc96a89fad69d45d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165310
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
As discussed on https://gerrit.libreoffice.org/c/core/+/164843/2#message-8873d3d119de7206b33bc824f5809b8b1d3d97da,
it is impossible at times to know in advance, if a specific code, that
must not be guarded by SolarMutex (e.g., calling to other threads, which
might need to grab the mutex), will itself be guarded by SolarMutex.
Before this change, a required pre-requisite for SolarMutexReleaser use
was existing lock of SolarMutex; otherwise, an attempt to release it
would call abort(). Thus, in some places we had to grab the mutex prior
to releasing it, and that itself introduced more potential for deadlock.
Now the SolarMutexReleaser is safe to use without the lock, in which
case, it will do nothing.
Change-Id: I8759c2f6ed448598b3be4d6c5109804b5e7523ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165262
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Both m_pOleComponent and the copy are rtl::Reference, so the copy
will ensure the lifetime of the object.
See https://gerrit.libreoffice.org/c/core/+/164986/2#message-5dd187741df3242f47d1037a1f9c9b0fd9bb1f8e
Change-Id: I092281ce41786682b269ba048f102877117391f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165013
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... which may need to be executed on a different thread.
Change-Id: Id9e4b86fd3eafa49139b21e3817aa1ee8aff3dba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164986
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
In a following scenario, there could be a crash:
1. Platform: a Windows system with MS Word installed.
2. LibreOffice is run in a listener mode;
3. A Java program opens a Writer document in a visible mode, with an
embedded Word OLE object;
4. It adds some text; then resizes the OLE object; then removes the
OLE object.
Word OLE objects have OLEMISC_RECOMPOSEONRESIZE flag [1]; this means,
that every re-layout of the document with this object must ask the
OLE server to re-layout the object content. So, the request thread
changes the document text, which triggers idle re-layout or redraw;
the idles start executing immediately in the idle main thread, with
solar mutex locked; then the request thread starts the OLE object
removal operation. The ongoing relayout in main thread would at some
stage need to execute a call to the OLE object, which temporarily
releases the solar mutex (this makes impossible using solar mutex to
synchronize the order of operations in this scenario). Other mutexes
guarding OLE object (in OleEmbeddedObject, and in OleComponent) are
also released for the duration of the call. Thus, the removal that
happens in the request thread proceeds, and the node containing the
OLE object is destroyed, while the main thread (processing exactly
this node) is waiting for the OLE server response, then for mutexes,
to proceed. After that, the main thread would attempt to access the
destroyed node object.
This change introduces a scheduler guard (a RAII object), that sets
a flag to not process idle events during the lifetime of the guard.
In its constructor, it also makes sure, that current pending idle
events are finished. This would make sure that guarded code started
from other threads would not race with idles potentially accessing
the model that is currently in transient state.
[1] https://learn.microsoft.com/en-us/windows/win32/api/oleidl/ne-oleidl-olemisc
Change-Id: I2ef0601ccd8b5872588a88493d1f43e39022dbed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164753
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I26617232049c6218b99d00e1f69adad42e8249ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164668
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I9d09cb02d5fed17d48f0bc42ac41cf8bad3b66b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164667
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Idc184c5155fa69888561fed5709da36c330d1c2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164666
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It was added in commit 7afe74c37ed737f9d7a7c9c77877a0bde6997771
(INTEGRATION: CWS os54 (1.21.10); FILE MERGED, 2005-03-11) for
issue #i30510# related to "StampIt". Hopefully now, after almost
20 years, the hack is not needed anymore.
Change-Id: Id39765b9d2c51fd487c48ce06382c068bab08959
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164459
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... to make sure that object methods are called in correct apartment
The user-visible problem was, that running a Java code that connects
to LibreOffice, and opening a document with an embedded OLE object
(it was Word object in a specific case, which needs activation at
opening stage, because these objects have OLEMISC_RECOMPOSEONRESIZE
flag), using loadComponentFromURL with "OnMainThread" set to true,
then closing the document, resulted in a hang after several hundreds
iterations. This was caused by Word process, that was started in
background to serve the COM calls, wasn't closed properly, and kept
all the objects in memory, until OOM.
The reason why it wasn't closed was failed call to IOleObject::Close
in OleComponent::CloseObject, which returned RPC_E_WRONG_THREAD,
because the activation of the OLE object happened in the main thread
(because of "OnMainThread"), which is STA, but closing happened in
the handler thread (belonging to MTA).
Similar problems previously were addressed in commits
2dc3a6c273cb82506842864481d78df7294debbf (framework: allow loading a
component on the main thread, 2018-12-20),
6002014ce0a5c9cea22c14b2437b7a508b2c72cb (framework: allow loading a
component on the main thread, using XDesktop, 2021-04-28),
d5cd62164d32273a25913c93aa04be9f7f3a4073 (embeddedobj: handle getting
the visible area on a thread, 2021-05-07).
These changes tried different workarounds for the same problem, when
a COM object instantiated in one apartment is later manipulated from
another, which fails. First two handled the case when the document
is loaded from a non-UI thread, and then manipulated with the UI; to
handle that, they introduced flags that delegated opening the file
to the main (UI) thread. The last change tried to handle the reverse
problem of the OLE object instantiated in the main thread was saved
in a handler thread, which again failed; the workaround was, again,
to try to delegate the second attempt to the main thread.
But basically all methods can fail in such circumstations, as shown
in this problem's case. The "OnMainThread" flag must be passed to
fileopen functions explicitly. Also, the workarounds only work by
passing everything to STA, and don't target a case when the calls
must be passed from STA to MTA.
Since Windows 2000, there is IGlobalInterfaceTable, which goal is
to solve this problem. It allows to use an intermediate object,
which can transparently delegate all calls to the correct thread.
This change re-implements how OLE objects are referenced from
OleComponentNative_Impl, using the said IGlobalInterfaceTable.
This should hopefully obsolete the previous workarounds, which
nevertheless are kept for now.
Change-Id: Ia1c590e547ed24a2c7389283aed6cc3d8ea024b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164457
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I2eead2d6907cf49d9a8525065d33c3ef43207660
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161779
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Do not require a reload of the current document for the
embedded objects to be disabled.
Also make sure the existing active embedded objects are
disabled when DisableActiveContent is enabled via options
dialog.
Change-Id: I5a8f302af0cac64575c3e5ec6dbe71ec50a15442
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164367
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
Change-Id: I5bcfe37adbf1f142950a1a2679f22333c711735e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164456
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
It's m_pViewObject2 that will be dereferenced below.
Change-Id: Ic3696953f013099ee2595a08428ba793c81b6b9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164455
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id9895a3b6e8c09df12c9f9c3c83e1432aa5fff71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... instead of manually loading and using OleUIInsertObjectA.
Change-Id: I597dd44e13edf8c94d83f434b57142c88e5aca6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163922
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove
non-const Sequence::begin()/end() in internal code, 2021-10-15) and
commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and try something a bit more generic
Change-Id: I1d8256576cd02f0a589df350ba7b53059dd586a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161250
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and fix some resulting symbol name clashes
Change-Id: I57b11494742ef74a97e0afb294b4e44813eaa249
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161074
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia560c123c2f9dd08acb7eeaafccee332dd16300e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161133
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
there was the possibility of constructing an OOoEmbeddedObjectFactory
or OleEmbeddedObjectFactory directly instead of
UNOEmbeddedObjectCreator.
So disable all createInstance calls for them too. Securing there won't
be active embedded objects.
Change-Id: Ib47ad920d4951790c12d1a8587505cab2f1e126d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160921
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Nowadays, MS Paint is optional component distributed through MS Store
(https://www.microsoft.com/store/productId/9PCFS5B6T72H); it may be
absent on some systems, resulting in tests relying on it failing.
[build CUT] embeddedobj_msole
[_RUN_____] testSaveOnThread::TestBody
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:207: Loaded object has no cached size!
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:232: OleEmbeddedObject::getVisualAreaSize: GetExtent() failed: com.sun.star.embed.UnreachableStateException message: "Class not registered
Bitmap Image at C:/lo/core/embeddedobj/source/msole/olecomponent.cxx:904" context: class OleComponent
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olecomponent.cxx:1142: OleComponent::GetCachedExtent: GetExtent() failed
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:257: OleEmbeddedObject::getVisualAreaSize: GetCachedExtent() failed: com.sun.star.lang.IllegalArgumentException message: "at C:/lo/core/embeddedobj/source/msole/olecomponent.cxx:1143" ArgumentPosition: 0
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olecomponent.cxx:1160: OleComponent::GetRecommendedExtent: GetExtent() failed
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:271: OleEmbeddedObject::getVisualAreaSize: GetRecommendedExtent() failed: com.sun.star.lang.IllegalArgumentException message: "at C:/lo/core/embeddedobj/source/msole/olecomponent.cxx:1161" ArgumentPosition: 0
warn:svtools.misc:123152:104988:svtools/source/misc/embedhlp.cxx:554: EmbeddedObjectRef::GetSize: no visual area size
warn:svtools.misc:123152:104988:svtools/source/misc/embedhlp.cxx:573: EmbeddedObjectRef::GetSize: empty size, defaulting to 5x5cm
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:207: Loaded object has no cached size!
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:232: OleEmbeddedObject::getVisualAreaSize: GetExtent() failed: com.sun.star.embed.UnreachableStateException message: "Class not registered
Bitmap Image at C:/lo/core/embeddedobj/source/msole/olecomponent.cxx:904" context: class OleComponent
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olecomponent.cxx:1142: OleComponent::GetCachedExtent: GetExtent() failed
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:257: OleEmbeddedObject::getVisualAreaSize: GetCachedExtent() failed: com.sun.star.lang.IllegalArgumentException message: "at C:/lo/core/embeddedobj/source/msole/olecomponent.cxx:1143" ArgumentPosition: 0
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olecomponent.cxx:1160: OleComponent::GetRecommendedExtent: GetExtent() failed
warn:embeddedobj.ole:123152:104988:embeddedobj/source/msole/olevisual.cxx:271: OleEmbeddedObject::getVisualAreaSize: GetRecommendedExtent() failed: com.sun.star.lang.IllegalArgumentException message: "at C:/lo/core/embeddedobj/source/msole/olecomponent.cxx:1161" ArgumentPosition: 0
warn:svtools.misc:123152:104988:svtools/source/misc/embedhlp.cxx:554: EmbeddedObjectRef::GetSize: no visual area size
warn:svtools.misc:123152:104988:svtools/source/misc/embedhlp.cxx:573: EmbeddedObjectRef::GetSize: empty size, defaulting to 5x5cm
C:/lo/core/test/source/xmltesttools.cxx:171:testSaveOnThread::TestBody
equality assertion failed
- Expected: 0.1665in
- Actual : 1.9685in
- In <>, attribute 'visible-area-width' of '//style:graphic-properties' incorrect value.
Check the class registration, and exit early if needed.
It is unclear if we should do something specific with MS Paint objects
on Windows, when MS Paint is absent, as we do on Linux; this is just
a quick workaround.
Similar checks might be needed in other tests.
Change-Id: I4d99bc3b13d84da53bdb5aa6259083a68ccc8871
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160597
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
adds new expert option DisableActiveContent
Right now only disables active embedded content / OLE.
If OLE content is being imported via
UNOEmbeddedObjectCreator::createInstanceInitFromEntry with the
expert option DisableActiveContent set, the imported OLE object is
now forced to be ODummyEmbeddedObject.
ODummyEmbeddedObject doesn't implement any other state then
embed::EmbedStates::LOADED (i.e. doesn't implement RUNNING,
ACTIVE etc.) which makes it possible to prevent the imported OLE
object becoming active.
The functions that now throw lang::NoSuchElementException are
usually called on new creation of embedded content via UI. But
since the call sites expect the possibility of embedded content
failing to initialize, that is handled by showing a popup stating
some form of `unable to insert`.
A follow-up improvement of disabling insertion of OLE content via
dialogs could be implemented.
Change-Id: Ib558a2a129b491798f5036a7bb269116545be75d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160402
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
Change-Id: I2761e0a093aff75c5660b2b78012277c67eb8e17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158191
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib1169d5c40ca87f789c71b48124754e073895fcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158054
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I2cb901e81de3b7db73cd2088348ddad46ae603dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158052
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
...by moving the char8_t -> char reinterpret_cast out of any potential constexpr
paths into a new TranslateId::getId. And demonstrate constexpr'ability by
making the aCategories var in OApplicationIconControl::Fill
(dbaccess/source/ui/app/AppIconControl.cxx) constexpr. (And there might be more
such cases that could now be made constexpr.)
Change-Id: I0b4e3292faf8f6b901f9b9e934e1aa6bf0f583ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157862
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
1. Pass its error message up the call stack as the exception's message.
2. In case of REGDB_E_CLASSNOTREG, also obtain the object's class name
and append it to the message.
3. Show this information in the message displayed for OLE activation
error.
This introduces a new SetExtendedMessage method in SfxErrorContext to
store extra information for specific errors.
Change-Id: Id3863276266d992ae407fbfa5568acf5c57aa96f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157372
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I80b6c736960badf1a6e3af89740a80f46a651f9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157305
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I6545cf93b0a101d3a3eea0abe9c1732fcf3dc2d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156850
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
regression from
commit 1ed765c818af2186e459c5ad0eff24dc39a20d34
tdf#155235 workaround gtk3 accessiblibility crashes on close
Change-Id: I1a43c7df6394426d8ce09ed382dcc6833dbe1c6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154893
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If90ff71d6a96342574799312f764badaf97980eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150349
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
no behaviour change intended
Change-Id: Ia1d12aa5c9afdc1347f6d4364bc6a0b7f41ee168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150341
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
calc does a lot of "CaptureMouse" which then leads to a lot of
"ReleaseMouse", I'm somewhat unconvinced that there should be any
CaptureMouse calls in there.
Change-Id: I7c44d2c36c89a5c32c525d65939723da9be77a72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149973
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If8c8e96c2d8365f10a191868e76e75d6fc7c5db9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149357
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: Ie212c86c6c0ac20878be88d88ade5eb1c989942d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148935
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
...as obsoleted by ef533553559fe09b4afab651fc692885d1acf4ed "Rudimentary support
for dynamic_cast on UNO proxy objects".
This reverts all of:
4cfcc9ac37b90ce64c8402a41eb4638adb185b5c "loplugin:unocast (framework::Desktop)"
03efbf72f4ddf7a84aa8aabef348331bd4b75e8a "loplugin:unocast
(vclcanvas::TextLayout)"
80099fdd51a69eaa6c36ca88ef772810e4a777fa "loplugin:unocast (SalGtkXWindow)"
cc147f576d8687fb79c77d47d41dc4ba1678a469 "loplugin:unocast
(sdext::presenter::CachablePresenterView)"
40db42be1d8fd0f9c6c8c5ba3767ddb9ee2034c2 "loplugin:unocast
(vclcanvas::CanvasFont)"
2d1e7995eae29e2826449eb5179f5fae181794a5 "loplugin:unocast (CairoColorSpace)"
4c0bbe4bd97636207cf71a6aa120c67698891da9 "loplugin:unocast
(canvas::ParametricPolyPolygon)"
89803666621c07d1b1ac9d3bd883f0ca192a91a0 "loplugin:unocast
(vclcanas::CanvasBitmap)"
d5e0c2c8db71878d21c2a7255af08cf5f9a6dd04 "loplugin:unocast
(sfx2::DigitalSignatures)"
c0c4519e0d5b555f59bbc04cc616454edfd1f4ce "loplugin:unocast
(VCLXAccessibleComponent)"
feb8b833a6245d42400f42a0bc789dc84594ee6f "loplugin:unocast (VCLXDialog)"
1fa58cc6cc9c3849753342a5d9a6ddfa461b5e66 "loplugin:unocast (VCLXMultiPage)"
f481f036deb1b1b46f3038074c4659f3a91b9c6c "loplugin:unocast
(DocumentSettingsSerializer)"
73df933f5fa5932f94e5a1b338a3eda00a9ce354 "loplugin:unocast
(css::embed::EmbeddedUpdate)"
420165ab0ef03c0467f9d17f504de2d2fc78f0e6 "loplugin:unocast
(canvas::tools' StandardColorSpace, StandardNoAlphaColorSpace)"
9abe8ee067e6c00f19d8a13346d53c4641c27166 "loplugin:unocast (MutableTreeNode)"
9f3022ceb036f23b4b0994c3e2fbd1001bff225a "loplugin:unocast (VCLXTabPage)"
1be70dda02c12a60778b7607cff2520ae1aa611e "loplugin:unocast
(vcl::unotools::VclCanvasBitmap)"
d6a70bb641b96e8e5616448c2378131ed62658b4 "loplugin:unocast
(basegfx::unotools::UnoPolyPolygon)"
5a14f009e6782c077463c8cbb8e9cea3d7950107 "loplugin:unocast
(xmlsecurity::Certificate)"
99009c9535dfa3e0d838989ccc7d84bfa2320ff4 "loplugin:unocast (sd::Annotation)"
0c7585c5fa78887e5459885ed744e8044fd76137 "loplugin:unocast (sd::TextApiObject)"
24e14afd1bfcaed6c200ab081973fba7e47267ca "loplugin:unocast
(SignatureVerifierImpl)"
1a7ad0c10d286ce9ae2700ceb2fd50eed1fb43a4 "loplugin:unocast
(pcr::PropertyEventTranslation)"
a97e2d2702d9a6f37775ccee2c08c4f3b2479c4b "loplugin:unocast (RangePageBreaks)"
19dfdf86ad1f5b08041d8b7a9f196caf881231ab "iloplugin:unocast
(pcr::OFormattedNumericControl)"
f9785ea595fd8e911f6370e836fa579225b9e571 "loplugin:unocast
(frm::OInterfaceContainer)"
5e5f40a4a92a31b0932c690219d002fcf18598cf "loplugin:unocast (ScVbaShapes)"
27b35b2c215b4832d4378ec3a7ecbba926552d06 "loplugin:unocast (ScVbaShapeRange)"
cb3108f860065928552a86cf8acc4b3a95718ecf "cid#1517812 Dereference null return
value"
feba0ddb1521d1142560fe54b7d7696ee910237f "loplugin:unocast
(weld::TransportAsXWindow)"
4d6c23216559eb48f9943bb49d6e475a6d64ba15 "loplugin:unocast
(oox::ForumlaImExportBase)"
4844c096a8ab6a9a620c410a0949d4499f12a504 "loplugin:unocast
(cairocanvas::SurfaceProvider)"
9a0b523e0a84d403b9092176ccec4b3e3efe42d0 "loplugin:unocast
(cairocanvas::CanvasBitmap)"
8a5648d8e59b4b007dbbf3824777c19a21efc61e "loplugin:unocast
(cairocanvas::TextLayout)"
28c27a0623bc78a0590858f97d03b620985bc84c "loplugin:unocast
(cairocanvas::CanvasFont)"
53bc223cb3288e32a417696ee61c29e5f01f209d "loplugin:unocast
(cairocanvas::RepaintTarget)"
5f70b0b9f6bc4ab145ddbd9155590ed4a3b1b9ec "loplugin:unocast (SvXMLImport)"
068187a898cdd2e26e9b16c348ecc1ed2dee3f29 "loplugin:unocast (VCLXWindow)"
88b4f966202717cd4ad38a30a8eda22c3e69ed35 "loplugin:unocast
(sfx2::sidebar::SidebarController)"
f1b7a69b280aefe2f1b3b0f32193494fd765f2bd "loplugin:unocast
(SvxLineStyleToolBoxControl)"
ba76f0ba7e8de4d2953739c952004b7d9af47197 "loplugin:unocast
(i18npool::Calendar_gregorian)"
840154daf934d8df52ead1cb7acd798c4d30f007 "loplugin:unocast
(framework::AddonsToolBarWrapper)"
b0e9c4c5f063cefa9557810e3349bdb9c7493091 "loplugin:unocast
(GrammarCheckingIterator)"
8ee6cfc9655ce9de4617cea1a0d9cb9d7a4fbfac "loplugin:unocast
(ucb::ucp::ext::Content)"
5b8cd77c112bc8c0e92b8fec215c3c8e802bbc0a "loplugin:unocast
(basic::SfxScriptLibraryContainer)"
9e73ff9fce12e102bb3c3cea8d8bb96c88f2c9ad "loplugin:unocast
(sdext::presenter::PresenterNotesView)"
a98acca8fbc38d3fd5600ae5056a8e42b6d8a40d "loplugin:unocast
(SelectionChangeHandler)"
c0b59ad6e35b0cb0dea0821e95f95569739078c1 "Consistently use
comphelper::getSomethingImpl<I>(aIdentifier, this)"
276e3ccbdd3259ec3daf8a1a98fa7f406b14e21c "loplugin:unocast
(vclcanvas::RepaintTarget)"
Change-Id: I37c73e3422a5154bf6cb647640d2d3f23db8bc34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145063
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ia0f628be9adf749ffdd9ad36ca9b1e8c98e29936
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144755
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Mostly com/sun/star/frame/Desktop.hpp is unused after inheriting from
UnoApiTest.
Change-Id: Ifba307353a11a14e033a230a291314bee86b51c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143190
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
so other places inheriting from UnoApiTest can also import/export
protected documents
Change-Id: I0e2716204dbb171c9e17e3939b266977e1b96dda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142592
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Id4c056734b6cd3cd1b699a473c32bd69cc949e80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142554
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
SwModelTestBase does the same. this will help to make
SwModelTestBase inherit from UnoApiTest
Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I26e0a4db8484c8e91f3ebff9828d76270ddc5f6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142256
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I35c883a1b05a797e83a41698fa205796e681d7c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141482
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
It sometimes crashes on windows. Switch to using the same
tearDown() logic as UnoApiTest::closeDocument, which
seems to be the most reliable variant of this kind of code.
Change-Id: I1493d6d265763b2aec4ee94f4ee66378dbe280b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141238
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which makes it easier to know what each variant requires
to stay on it's happy path
Change-Id: I3275a2543573367714bc78092e882f6535507285
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140469
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|