which is often a useful indicator that the callers can be made to use
std::unique_ptr
Change-Id: Idb1745d1f58dbcf389c9f60f1a5728d7d092ade5
Reviewed-on: https://gerrit.libreoffice.org/56238
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
collection of heuristics to look for local variables that are never read
from i.e. do not contribute to the surrounding logic
This is an expensive plugin, since it walks up the parent tree,
so it is off by default.
Change-Id: Ib8ba292241bd16adf299e8bba4502cb473513a06
Reviewed-on: https://gerrit.libreoffice.org/52450
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Regression from e80aef4e03
The InternetQueryOption has two variants: ANSI (A) and Unicode (W)
(see https://msdn.microsoft.com/en-us/library/aa385101).
INTERNET_PROXY_INFO struct we are using is defined to contain two
LPCTSTR members (see https://msdn.microsoft.com/en-us/library/aa385148).
When UNICODE is defined, InternetQueryOption expands to W variant,
and at the same time, all MS-specific generic string types (like
TCHAR or LPCTSTR) are expanded to wchar_t-based types.
So, the expectation is that InternetQueryOptionW fills the struct
with pointers to widechar strings.
But actually this is not true: InternetQueryOptionW still returns
char-based strings in the struct; so just revert partially commit
above.
Change-Id: I0facb1baf2a191f7bafdf185e684bfe741ca677a
Reviewed-on: https://gerrit.libreoffice.org/51629
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When sending e-mail using a MAPI mail client that doesn't recognize
MAPI_DIALOG_MODELESS flag, and doesn't return from MAPISendMail until
message compose dialog is closed (like MS Outlook 2010 and older),
waiting for the senddoc process blocks UI, which is unexpected and
prevents users from copying stuff from documents to the mail body.
Waiting for senddoc process completion is used for two things:
1. To serialize sending multiple mails (e.g., using mailmerge);
2. To show error in case when it failed.
This patch allows to avoid blocking the UI in case when compose UI is
requested - i.e., user interaction with the mail client is expected,
and serialization is not required. In this case, the senddoc process
will show the error message itself -> no need for main application to
wait for its return. The error message now includes actual error code.
To avoid cases when closing main program would remove temporary
attachment files before they were used by mail client, they are
copied to base temporary directory (instead of default session
temporary directory that gets deleted upon program shutdown).
senddoc cleans up its temporaries itself.
The temporary attachment files are copied to files with ASCII-only
filenames, and their original filenames are passed to mail clients
using MAPI. This allows to avoid cases when the filenames contain
characters outside of current Windows codepage, and the mail client
does not support Unicode MAPI, thus receiving wrong filename and
erroring out from the send.
Change-Id: I4a517bd7a797e76e4c0b7ea48bb1a7b652741a81
Reviewed-on: https://gerrit.libreoffice.org/50826
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When sending mail using MS Outlook, our UI gets locked until user
closes the Outlook's compose message window.
This patch uses Outlook 2013+ option to show modeless window.
Change-Id: Ib99b4440cd20a8bff0c7cd96838b31a2d14bd804
Reviewed-on: https://gerrit.libreoffice.org/50476
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
This is mostly a copy of the KDE4 backend ported to Qt5/KF5.
One difference is that this code will initialize the QApplication
on-demand, when it's not yet available. This will allow us to use
this desktop backend also within a vclplug that does not use Qt
itself, such as the upcoming Gtk3/KDE5 hybrid.
Change-Id: I5cf96ac5729608c82a58eead6723a38f014ba875
Reviewed-on: https://gerrit.libreoffice.org/47716
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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>
Automatic rewrite (of loplugin:cstylecast and loplugin:unnecessaryparen) after
cab0427cad "Enable loplugin:cstylecast for some
more cases" and a409d32e7f "More
loplugin:cstylecast"
Change-Id: Iff4877e8a42804c952c48c13332caf0a83c92870
Reviewed-on: https://gerrit.libreoffice.org/48216
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: Ifb1f116ca0af7d0a8a6bdc6a16f6cc5e1c9e3a6a
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The backend's ImplGetLocale() didn't handle variants, so
ca_ES@valencia ended up as ca-ES instead of ca-ES-valencia, which
made a difference with for example the UI language being set to
Default resulting in only ca instead of ca-valencia, which then
is also written to /org.openoffice.Setup/L10N/ooLocale during
startup and obtained later.
This only for the *iX branch, no idea if and what could be
adjusted for Windows or MacOSX.
Change-Id: I050f6f643571ccdc669fb91b06f3bb516f96e8d5
Reviewed-on: https://gerrit.libreoffice.org/45946
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
https://msdn.microsoft.com/en-us/library/ms679351 describes that
"it is unsafe to take an arbitrary system error code returned from an API
and use FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSERTS"
Previously in case when an error string would contain inserts, function
returned error, so the error message wasn't shown (at least it didn't
crash, thanks to nullptr as the function's last argument).
As the function may fail, we now pre-nullify the buffer pointer to avoid
dereferencing uninitialized pointer later (though at least for some
Windows versions, the function nullifies the pointer in case of
FORMAT_MESSAGE_ALLOCATE_BUFFER, but there's no explicit guarantee of this).
Also release of allocated buffer is changed to recommended use of
HeapFree.
The code that doesn't make use of OUString is left directly calling
FormatMessage, to avoid introducing new dependencies. Where it makes
sense, we now use WindowsErrorString from <comphelper/windowserrorstring.hxx>
Change-Id: I834c08eb6d92987e7d3d01e2c36ec55e42aea848
Reviewed-on: https://gerrit.libreoffice.org/44206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
