By creating deleted methods for the wrong calls.
Avoids the compiler needing to construct a temporary
Change-Id: I3b8c648d6bb22d22827bf74f21ea5a2a17fc0f6a
Reviewed-on: https://gerrit.libreoffice.org/72103
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Also use scope where possible. This allows to limit guard scope at
language level; visualises the scope clearly; and helps avoiding
errors like fixed in commit 61e4437c85.
Change-Id: Ifeca96e2df8e8a0897770d9546b2536806275f41
Reviewed-on: https://gerrit.libreoffice.org/70376
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... unlike GetMetaFileBitsEx or GetEnhMetaFileBits, which are used
in the other branches. The implementation is trying to pass nullptr
to the function since commit 41e72962df
Just calculate the required buffer size using BITMAP struct filled
by GetObject call.
V575 The null pointer is passed into 'GetBitmapBits' function.
Inspect the third argument.
Change-Id: I0d164694c99d805fd59b65ea1b4df4919a89e130
Reviewed-on: https://gerrit.libreoffice.org/70012
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
V572 It is odd that the object which was created using 'new' operator
is immediately cast to another type.
Change-Id: I6d1523e71b3e06be1cf41abaabb44e49fe11cd8e
Reviewed-on: https://gerrit.libreoffice.org/69369
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The "hides" the hack for native Windows dialogs introduced in
commit 5bb798a99e ("tdf#117295 WIN no main loop shortcut for
OLE dialog") in its own header.
Change-Id: I1f36aad20dec50ae1f296001b51085989afb19f6
Reviewed-on: https://gerrit.libreoffice.org/65100
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Normally we handle Idle events directly without posting events
to the main event queue, as there seem to be no way to post them
to the end of the queue and this starves system events.
This prevents using this short-cut, as the default Windows event
processing doesn't know of this special handling.
Eventually this hack should be removed by simply always processing
all pending events...
Change-Id: If9ae81ca7e847743f9251343e106dbf566371584
Reviewed-on: https://gerrit.libreoffice.org/65040
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
It is expected that if you load an OLE2 storage (from reqif-xhtml) and
you save it as ODT, the OLE2 data is not modified. This was almost the
case, but we insisted on removing the OLE2 preview from the storage.
Add a new flag to OleEmbeddedObject, so import filters can opt in for
not modifying the OLE2 data.
[ The nice situation is that we already had a test file which had a
preview stream in the OLE2 storage, so we can easily assert there that
the size doesn't change. ]
Change-Id: I9b8b29f015dd4f2513e51a1066767218580cb5d8
Reviewed-on: https://gerrit.libreoffice.org/63381
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Regressions from commit 45519023aa44 ("Resolves: tdf#119997
toolbar layout unlock doesn't refresh ui"), commit c5977a89c2
("Resolves: tdf#96451 do magic to enable embedded chart sidebar
only for chart") and commit faed29cac9 ("for now show chart
sidebar").
It also adds an assert for the underflow, as nobody cared for
the underflow warnings since some years.
Change-Id: I86bb093987f084c85a7b640a846dfe0aefea9e48
Reviewed-on: https://gerrit.libreoffice.org/63204
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The deadlock happens from time to time, when converting documents
containing OLE objects via remote UNO (from Java) -- after the
conversion, when closing the document.
The relevant stacktraces are:
>Debug.ListCallStack /ShowLineOffset /AllThreads
Callstack for Thread 8 (Thread Id: 32912 (0x8090)):
...
6 sal3.dll!osl_acquireMutex(_oslMutexImpl * Mutex) Line 75
7 [Inline Frame] emboleobj.dll!osl::Mutex::acquire() Line 56
8 [Inline Frame] emboleobj.dll!osl::Guard<osl::Mutex>::{ctor}(osl::Mutex &) Line 129
9 emboleobj.dll!OleComponent::OnClose_Impl() Line 1399
10 emboleobj.dll!OleWrapperAdviseSink::OnClose() Line 119
Callstack for Thread 11 (Thread Id: 21088 (0x5260)):
...
11 ole32.dll!00007fffc5e44e83()
12 [Inline Frame] emboleobj.dll!OleComponent::CloseObject() Line 1012
13 emboleobj.dll!OleComponent::Dispose() Line 484
14 emboleobj.dll!OleComponent::close(unsigned char bDeliverOwnership) Line 1463
15 emboleobj.dll!OleEmbeddedObject::GetRidOfComponent() Line 239
16 emboleobj.dll!OleEmbeddedObject::Dispose() Line 275
17 emboleobj.dll!OleEmbeddedObject::close(unsigned char bDeliverOwnership) Line 497
...
26 swlo.dll!SwXTextDocument::close(unsigned char bDeliverOwnership) Line 617
OleComponent::OnClose_Impl() taking a lock is fine, but
OleComponent::close() takes a lock and then later it still calls out
(via OleComponent::CloseObject()), which is a no-go.
Fix the problem by making sure that callers of Dispose() own no lock at
the time of the function call, and taking the lock in Dispose() only
after the CloseObject() call (which invokes event listeners).
Change-Id: I53befee21478188c7f79723b7d7596e66077d1c2
Reviewed-on: https://gerrit.libreoffice.org/63014
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
and simplify callsites to use it instead of the current
"seek to end, find pos, seek back to original pos"
pattern
Change-Id: Ib5828868f73c341891efc759af8bd4695ae2f33c
Reviewed-on: https://gerrit.libreoffice.org/61738
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I04c5ba277d5b3398c07de6ae66713d977636088d
Reviewed-on: https://gerrit.libreoffice.org/61347
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Including:
* expanding STDAPI to its definition (as per
<https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add
__declspec(dllexport) into its middle, in
extensions/source/activex/so_activex.cxx; as discussed in the comments at
<https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in
setup_native, use __declspec(dllexport)", having a function both listed in a
.def file EXPORTS and marking it dllexport is OK, and the latter helps the
heuristics of loplugin:external; however, the relevant functions in
extensions/source/activex/so_activex.cxx probably don't even need to be
exported in the first place?
* follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx
Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191
Reviewed-on: https://gerrit.libreoffice.org/60938
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ib420e9216b8313f5ed7634ec375e39ceb741fd45
Reviewed-on: https://gerrit.libreoffice.org/59297
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
This is a continuation of commit 6ff2d84ade to be able to remove those unneeded includes.
This commit adds missing headers to every file found by:
grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
to directories from dbaccess to extensions
Change-Id: I4d15aa35e11664ef78c836ffc2937c7e0bb6ea59
Reviewed-on: https://gerrit.libreoffice.org/58165
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Since the previous call would throw if there was nothing to be assigned
to the value.
Idea from tml.
Used the following script to find places:
git grep -A3 -n UNO_QUERY_THROW | grep -B3 -F 'is()'
Change-Id: I36ba7b00bcd014bdf16c0455ab91056f82194969
Reviewed-on: https://gerrit.libreoffice.org/55417
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Embedded native data (what we don't parse just carry on) and real OLE2
embedding already worked, this adds the case where the actual content is
ODF, just inside OLE2.
The DOC import/export had support for handleing ODF content inside OLE2,
so reuse that code: add new functions to SvxMSDffManager for import
purposes and reuse SvxMSExportOLEObjects for export purposes.
Change-Id: I0acf65d4bf29af896b8f1dd625e8672050aae350
Reviewed-on: https://gerrit.libreoffice.org/55088
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(*) if we are already throwing a Wrapped*Exception, get the
exception using cppu::getCaughtexception.
(*) when catching and then immediately throwing UNO exceptions,
use cppu::getCaughtException to prevent exception slicing
(*) if we are going to catch an exception and then
immediately throw a RuntimeException, rather throw a
WrappedTargetRuntimeException and preserve the original exception information.
Change-Id: Ia7a501a50ae0e6f4d05186333c8517fdcb17d558
Reviewed-on: https://gerrit.libreoffice.org/54692
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel Grandin