based on OInterfaceContainerHelper2 which is considerably
faster than the original OInterfaceContainerHelper
Change-Id: Ia8cdbc5ef877a7af3d9193e1bb2faf1595c15470
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120165
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
But GetMessageW encodes more than true vs. false in its BOOL return value, so
silence the unhelpful loplugin with auto.
Change-Id: I77d053b760e93f918367532c63a6dfe963faa12d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110645
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This also fixes a regression from commit
4342e22060,
which had made o2u_attachCurrentThread a no-op.
From 2006, this initialization had never been executed.
Is it unnecessary after all?
Change-Id: I2ff942a913fa844f5e4627ba23ca34d1b864846b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110217
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
GetMessageW returns a BOOL with three defined return values; a
bit unexpected (-1 = error, 0 = WM_QUIT, * = dispatch message).
So this tries to handle the non-dispatch results in some way.
It's not clear for me, if there is some sensible way to "recover"
from an error, but from all I've read it doesn't look like it.
"Recover" means in this case, that the last call failed but next
call may still succeed without changing the parameters.
Change-Id: Ib1f366c7ce8b48158d1935938b49d8da991b30e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110043
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
to make it more obvious when we are constructing heap OUStrings
code and potentially inadvertently throwing away performance.
And fix a handful of places so revealed.
Change-Id: I0cf390f78026f8a670aaab53424cd31510633051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...and in turn add OUString::operator = and OUString::operator +=
overloads that take a std::u16string_view. Without making the ctors explicit,
the operator overloads would have caused ambiguities when called with raw
sal_Unicode pointers/non-const arrays, as those can convert to both OUString and
to std::u16string_view.
But the std::u16string_view operator overloads will generally be useful when
changing OUStringLiteral similarly to 4b9e440c51
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which
point many existing uses of OUStringLiteral will be replaced with uses of
std::u16string_view.
Implementing this change turned up a need for an operator = overload for
OUStringNumber, which has thus been added. No such need turned up for a
corresponding operator += overload, but which can easily be added when the need
arises.
It also revealed that the operator == overloads between an OUString and a raw
sal_Unicode pointer/non-const array were implemented rather inefficiently,
creating a temporary OUString from the raw argument. Those have been improved.
Preceding commits have already taken care of many dubious or simply unnecessary
implicit uses of the now-explicit OUString ctors. This commit makes explicit
the few remaining reasonable uses. (And in some cases needed to change variable
initialization syntax from using parentheses to using curly braces, to avoid the
most vexing parse issue. And needed to explicitly add OUString ctors from
char16 const[2] string literal lvalues in a conditional expression in
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary
because MSVC apparently still insists on doing array-to-pointer decay there.)
All of this only affects LIBO_INTERNAL_ONLY.
Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and fix bug in GenericClipboard::initialize, where it was looping through
the arguments, but always reading the first one.
I'm guessing it was never an issue because it is always called with
only one argument
Change-Id: I8f72b6bce8c77a69c7d75115e34630e2c308261e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94553
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The receiving end, VCLXToolkit::createSystemChild in
toolkit/source/awt/vclxtoolkit.cxx, already extracts a sal_Int64 from the Any.
Change-Id: I758345281a9aafa4eaa27dd31e47e43981df205a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90826
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
"conversion from 'ATOM' (aka 'unsigned short') to 'BOOL' (aka 'int')"; if the
BOOL return value of winwrap::HatchWindowRegister hasn't been used in bad ways
in the past, this should have been safe in the past, converting from smaller
ATOM to larger BOOL
Change-Id: I836aee56384a01ef0d959ecc5dbebc923acb642b
Reviewed-on: https://gerrit.libreoffice.org/83209
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Replace them with default initialization or calloc
Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1
Reviewed-on: https://gerrit.libreoffice.org/80805
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
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>
Automatic rewrite (of loplugin:cstylecast and loplugin:unnecessaryparen) after
cab0427cad "Enable loplugin:cstylecast for some
more cases" and a409d32e7f "More
loplugin:cstylecast"
Change-Id: Ib3355159dd08333e1b7a8d091caf2069cdcc7862
Reviewed-on: https://gerrit.libreoffice.org/48317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Previosly (since commit 9ac98e6e34)
it was expected to gradually remove SAL_U/W usage in Windows code
by replacing with reinterpret_cast or changing to some bettertypes.
But as it's useful to make use of fact that LibreOffice and Windows
use compatible representation of strings, this commit puts these
functions to a better-suited o3tl, and recommends that the functions
be consistently used throughout Windows-specific code to reflect the
compatibility and keep the casts safe.
Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6
Reviewed-on: https://gerrit.libreoffice.org/43150
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Noel Grandin