the last caller was removed in
commit 508ea2d571
Author: Kurt Zenker <kz@openoffice.org>
Date: Mon Oct 4 18:53:05 2004 +0000
INTEGRATION: CWS mav09 (1.6.2); FILE MERGED
2004/08/18 12:24:34 mav 1.6.2.4: #i27773# use system fallback
2004/06/24 17:13:42 mav 1.6.2.3: #i27773# reactivate linking support for OOo documents
2004/06/18 14:17:55 mba 1.6.2.2: #i27773#: special objects don't have a hatchwindow
2004/06/10 16:19:50 mav 1.6.2.1: #i27773# use configuration for conversion purposes
and I cannot find any indication of external use
Change-Id: If895bd2309db8f16729ae0854d6d339f3525ff55
Signed-off-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3876
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 67f1434988c3ac51759f4d392daa728c1bfbaeb5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206188
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
c00a23393a gated the whole OLE-link
conflict detection on HAVE_FEATURE_MULTIUSER_ENVIRONMENT, but only
svt::DocumentLockFile and svt::MSODocumentLockFile actually need it.
follow-up of: c00a23393a
Change-Id: I6552e8bee3731f56409e7f7342c524f56182fe74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205095
Reviewed-by: Balazs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins
After reverting 2b4cd99d, editing an OLE link whose source is already
open in this LO instance produces a sharing-violation on save (the
intra-process scenario tdf#126742 was working around).
Detect the conflict at doVerb, gated to verbs targeting a visible
state so internal RUNNING transitions aren't intercepted. If the
source is loaded as another visible frame in this LO, switch to that
window (matches MSO behaviour). Otherwise probe for any .~lock or
MSO ~$ file - foreign user, hidden own frame, or stale own lock from
a crash - and show an async warning with the lock owner. In all
cases the OLE working copy is never created. Skipped in headless
mode.
Change-Id: Ic87bb6f073b0b04ec47597cc15f2c5a83cc2bffc
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2004
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204940
Reviewed-by: Balazs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I5b23b02151c75bb49831a2bbf8d515eb0b54415e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199068
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
this was skipped in previous runs, since it contains some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: If1e3e3c7c0fc14ed6e8b51174a0e7f1220fdbc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197496
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
1. Avoid explicitly specifying COM_QUERY in calls to QueryInterface
(it is implied from the name).
2. Drop redundant ctor and set() that duplicate QueryInterface.
3. Allow ThrowIfFailed without a message.
Change-Id: I75b545e534efb7e57da131dfd40a2a49d204efac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198033
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[q-w]*
This shaves off about 100M input
Change-Id: Ib4d0af44b383d34d856a9797fe70a974b359402f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196398
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Replace by operator[], begin() and end(), which don't have overhead
since commit 2484de6728 (Remove non-
const Sequence::begin()/end() in internal code, 2021-10-15)
and commit fb3c04bd19 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: I221470b3439bb0dc6e7705b0d99deb3cd2063484
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195176
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Whatever that was intended to mean: if that meant that the constants
were encoded that way, these are UTF-16 already; is that meant that
they only contained characters in that range, that is unimportant.
Change-Id: I5463f1fca0d552a93d3c9d487ed9912c9e1a989e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191240
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Previously, WindowsErrorString and WindowsErrorStringFromHRESULT were
defined in an anonymous namespace in windowserrorstring.hxx, which:
1. Made them unavailable to other translation units
2. Violate ODR by creating separate copies in each TU
3. Require workarounds to access them
Changes:
- Move functions to proper comphelper namespace
- Keep implementations inline as they're simple utilities
- Preserve all existing functionality
- Update all call sites to use comphelper:: prefix
This change enables proper use of these utilities across LibreOffice
while maintaining current behavior and performance characteristics.
Introduced in this commit:
commit 94cdcaa4d8
Author: Tor Lillqvist <tml@collabora.com>
Date: Thu Aug 13 13:22:28 2015 +0300
Add a globally usable WindowsErrorString function
Change-Id: I34df1c2b1f30c6204f107ca4792131d692203880
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183332
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
This is an attempt to reduce areas that execute with mutex unlocked
because the called code may deadlock. Also, this copies objects on
stack before unlocking, using lambdas' own variables.
I hope that it somewhat improves reliability. OTOH, this runs more
code with lock active, has a potential of new deadlocks, so risky.
Change-Id: I558b7f5f18f63622fed3a9c3978327d0d76fe90d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172237
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The request thread was calling OleComponent::CloseObject, which executed
on main thread; OleEmbeddedObject::m_aMutex as locked by request thread:
emboleobj.dll!OleComponent::CloseObject() Line 1004
emboleobj.dll!OleComponent::Dispose() Line 451
emboleobj.dll!OleComponent::close(unsigned char bDeliverOwnership) Line 1513
emboleobj.dll!OleEmbeddedObject::GetRidOfComponent() Line 235
emboleobj.dll!OleEmbeddedObject::Dispose() Line 269
emboleobj.dll!OleEmbeddedObject::close(unsigned char bDeliverOwnership) Line 498
comphelper.dll!comphelper::EmbeddedObjectContainer::CloseEmbeddedObjects() Line 208
sfxlo.dll!SfxObjectShell::~SfxObjectShell() Line 322
swlo.dll!SwDocShell::~SwDocShell() Line 380
swlo.dll!SwDocShell::`vector deleting destructor'(unsigned int)
cppuhelper3MSC.dll!cppu::OWeakObject::release() Line 229
sfxlo.dll!rtl::Reference<SfxObjectShell>::~Reference<SfxObjectShell>() Line 126
sfxlo.dll!IMPL_SfxBaseModel_DataContainer::~IMPL_SfxBaseModel_DataContainer() Line 265
sfxlo.dll!IMPL_SfxBaseModel_DataContainer::`scalar deleting destructor'(unsigned int)
sfxlo.dll!std::_Destroy_in_place<IMPL_SfxBaseModel_DataContainer>(IMPL_SfxBaseModel_DataContainer & _Obj) Line 293
sfxlo.dll!std::_Ref_count_obj2<IMPL_SfxBaseModel_DataContainer>::_Destroy() Line 2113
sfxlo.dll!std::_Ref_count_base::_Decref() Line 1164
sfxlo.dll!std::_Ptr_base<IMPL_SfxBaseModel_DataContainer>::_Decref() Line 1380
sfxlo.dll!std::shared_ptr<IMPL_SfxBaseModel_DataContainer>::~shared_ptr<IMPL_SfxBaseModel_DataContainer>() Line 1685
sfxlo.dll!std::shared_ptr<IMPL_SfxBaseModel_DataContainer>::reset() Line 1732
sfxlo.dll!SfxBaseModel::dispose() Line 794
swlo.dll!SwXTextDocument::dispose() Line 561
sfxlo.dll!SfxBaseModel::close(unsigned char bDeliverOwnership) Line 1523
swlo.dll!SwXTextDocument::close(unsigned char bDeliverOwnership) Line 574
sfxlo.dll!SfxBaseModel::dispose() Line 745
swlo.dll!SwXTextDocument::dispose() Line 561
mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214
mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 430
binaryurplo.dll!binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny * returnValue, std::vector<binaryurp::BinaryAny,std::allocator<binaryurp::BinaryAny>> * outArguments) Line 239
binaryurplo.dll!binaryurp::IncomingRequest::execute() Line 79
binaryurplo.dll!request(void * pThreadSpecificData) Line 84
cppu3.dll!cppu_threadpool::JobQueue::enter(const void * nDisposeId, bool bReturnWhenNoJob) Line 101
cppu3.dll!cppu_threadpool::ORequestThread::run() Line 165
cppu3.dll!threadFunc(void * param) Line 190
sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67
Main thread was acquiring OleEmbeddedObject::m_aMutex, which deadlocked:
sal3.dll!osl_acquireMutex(_oslMutexImpl * Mutex) Line 65
emboleobj.dll!osl::Mutex::acquire() Line 63
emboleobj.dll!osl::ResettableGuard<osl::Mutex>::reset() Line 250
emboleobj.dll!OleEmbeddedObject::setVisualAreaSize(__int64 nAspect, const com::sun::star::awt::Size & aSize) Line 148
swlo.dll!SwWrtShell::CalcAndSetScale(svt::EmbeddedObjectRef & xObj, const SwRect * pFlyPrtRect, const SwRect * pFlyFrameRect, const bool bNoTextFramePrtAreaChanged) Line 777
swlo.dll!SwContentNotify::ImplDestroy() Line 926
swlo.dll!SwContentNotify::~SwContentNotify() Line 1037
swlo.dll!SwNoTextFrame::MakeAll(OutputDevice * pRenderContext) Line 584
swlo.dll!SwFrame::OptPrepareMake() Line 412
swlo.dll!SwFrame::OptCalc() Line 1110
swlo.dll!SwLayAction::FormatContent_(const SwContentFrame * pContent, const SwPageFrame * pPage) Line 1960
swlo.dll!SwLayAction::FormatFlyContent(const SwFlyFrame * pFly) Line 1985
swlo.dll!SwObjectFormatter::FormatObj_(SwAnchoredObject & _rAnchoredObj) Line 312
swlo.dll!SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject & _rAnchoredObj, const bool _bCheckForMovedFwd) Line 133
swlo.dll!SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame * _pMasterTextFrame) Line 414
swlo.dll!SwObjectFormatterTextFrame::DoFormatObjs() Line 348
swlo.dll!SwObjectFormatter::FormatObjsAtFrame(SwFrame & _rAnchorFrame, const SwPageFrame & _rPageFrame, SwLayAction * _pLayAction) Line 160
swlo.dll!SwLayAction::FormatContent(SwPageFrame * pPage) Line 1793
swlo.dll!SwLayAction::InternalAction(OutputDevice * pRenderContext) Line 605
swlo.dll!SwLayAction::Action(OutputDevice * pRenderContext) Line 389
swlo.dll!SwLayIdle::SwLayIdle(SwRootFrame * pRt, SwViewShellImp * pI) Line 2363
swlo.dll!SwViewShell::LayoutIdle() Line 827
swlo.dll!sw::DocumentTimerManager::DoIdleJobs(Timer * __formal) Line 176
swlo.dll!sw::DocumentTimerManager::LinkStubDoIdleJobs(void * instance, Timer * data) Line 156
vcllo.dll!Link<Timer *,void>::Call(Timer * data) Line 111
vcllo.dll!Timer::Invoke() Line 75
vcllo.dll!Scheduler::CallbackTaskScheduling() Line 509
vcllo.dll!SalTimer::CallCallback() Line 53
vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 169
vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 525
vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 581
vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 385
vcllo.dll!Application::Yield() Line 473
vcllo.dll!Application::Execute() Line 361
sofficeapp.dll!desktop::Desktop::Main() Line 1652
vcllo.dll!ImplSVMain() Line 229
vcllo.dll!SVMain() Line 262
sofficeapp.dll!soffice_main() Line 110
soffice.bin!sal_main() Line 51
soffice.bin!main(int argc, char * * argv) Line 49
soffice.bin!invoke_main() Line 79
soffice.bin!__scrt_common_main_seh() Line 288
soffice.bin!__scrt_common_main() Line 331
soffice.bin!mainCRTStartup(void * __formal) Line 17
Change-Id: Iaf5133c488d4f26f43530ea19584e99cce12d81e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171855
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The method itself clears its own guard; the caller still holding the
guard results in hangs seen in some Java code.
See also commit e2bfc34d14 (Reimplement
OleComponentNative_Impl to use IGlobalInterfaceTablem 2024-03-11).
Change-Id: Ib22e71e7500ccceb946f7b1d6606f8f61ae2afe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169315
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
In commit e2bfc34d14 (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>
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>
Andrea Gelmini