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>
V572 It is odd that the object which was created using 'new' operator
is immediately cast to another type.
Change-Id: I54976062dc3f62eaaa79f89eff54454f0b24ac2c
Reviewed-on: https://gerrit.libreoffice.org/69989
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This reverts commit 3d8c159841, and
instead, checks if the MtaOleReq window is not destroyed yet, in
addition to the wait for the condition. This allows to avoid wait
forever for condition which never gets signalled, and process the
sent messages when waiting.
The window's WM_DESTROY handler sets the event signalling that.
The Win32Condition's wait() is changed to take the abort event,
and return true if its own event fired, and false if abort event
fired.
Change-Id: I1861dd3dabb39329976a3ccf2a5392c9ddbf9613
Reviewed-on: https://gerrit.libreoffice.org/67383
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The window can be destroyed by e.g. WM_QUERYENDSESSION/WM_ENDSESSION
sequence, and then the message MSG_REGCLIPVIEWER handler would not run
and the condition would never be set.
Since we need to wait for the message processed, let's just use sendMessage
which would return only after the message has been processed anyway, and
also will return immediately on failure (e.g., window handle invalid).
Also this changes other cases where postMessage + wait pattern was used,
and removes the condition from MsgContext.
Change-Id: Ic12deafbaedd1cc99b9d6145650d99069c618f0e
Reviewed-on: https://gerrit.libreoffice.org/62881
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This was using the SfxPoolItem serialisation of XATTR_FILL* items,
where only XFillColorItem and XFillStyleItem were actually used;
the binary serialisation was removed without being aware of this
feature.
Fix this by using uno::Any instead, rather than reviving the binary
serialisation.
Also change the clipboard format strings, just to be safe.
(regression from 97b889b8b2)
Change-Id: I1828621a9aae606a1ca47835eef608062efe64a0
Reviewed-on: https://gerrit.libreoffice.org/62455
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
CMimeContentType::m_ParameterMap isn't modified after construction
Change-Id: Ib3dbfbd4212ed0d7e8a9f29c655f935d3fc4f1bf
Reviewed-on: https://gerrit.libreoffice.org/61698
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that had accidentally not been removed along with the definitions in
b75e3ded1f "tdf#120158: Base CMimeContentType on
INetMIME::scanContentType"
Change-Id: If94c0c413b891480c12a098c7b15caa1422213b0
Reviewed-on: https://gerrit.libreoffice.org/61697
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...instead of using yet another local implementation of parsing media types.
CMimeContentType is the implementation of the UNO
css.datatransfer.XMimeContentType interface. One observable change in behavior
is that type, subtype, and parameter names will now always be reported in lower
case instead of with the casing from the input preserved (but those differences
in casing are functionally equivalent per the media type specification). Also,
parameter names supplied to the hasParameter and getParameterValue functions are
now also treated case-insensitive.
The upside of this change is that INetMIME::scanContentType (via "The encoding
of rMediaType should be US-ASCII, but any Unicode values in the range U+0080..
U+FFFF are interpreted 'as appropriate.'") already implicitly supports RFC 6532
"Internationalized Email Headers" extensions for media types, allowing quoted-
string parameter values to contain non-ASCII Unicode characters.
That means that tfd#120158 "Impossible to paste special in Writer from Calc in
Libreoffice 6.1.x in some UI languages - the dialogue caption says 'unknown
source'" can be fixed by just allowing non-ASCII typename parameters being
generated in ImplGetParameterString in svtools/source/misc/transfer.cxx, and
reverting the problematic (see the comments there) previous fix
<https://gerrit.libreoffice.org/61601> "tdf#120158: fix ImplGetParameterString
for typename". (Which will be done in a follow-up commit, to ease potential
backporting, as that previous fix has already been backported to some versions
but not to others.)
Change-Id: I5d4d3586e8046f288a97605b000e262a8db5a4e9
Reviewed-on: https://gerrit.libreoffice.org/61684
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Just keep the definition of _WIN32_WINNT in windows.mk, which
claims it automatically derivates WINVER in some sdk header.
Change-Id: I0a83e91ffdc9e0fc847433a92a45424fbfcb189c
Reviewed-on: https://gerrit.libreoffice.org/61631
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Although the IEnumFORMATETC::Next documentation only mentions S_OK and
S_FALSE, there are error codes that also may be returned: e.g.,
0x800706BA RPC server unavailable (encountered locally in a unit test).
In that case, this used to loop infinitely.
We are only interested in S_OK result, so check for it.
Change-Id: I062e409e84efb68353321f7c48d922ec83191f73
Reviewed-on: https://gerrit.libreoffice.org/61621
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
