Age | Commit message (Collapse) | Author | Files | Lines |
|
Regression from
commit 9a6527a98fb968b3fe6bc293ff7520a9480d43d0
CommitDate: Mon Jun 27 21:57:52 2016 +0200
stringToDouble() do not parse separator without digit as 0.0
Change-Id: I9d90aedc324ef0938297224297d89817e3fd1e90
Reviewed-on: https://gerrit.libreoffice.org/56028
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 5c0783cecb0b141885a25ca26220614ad3125f8e)
Reviewed-on: https://gerrit.libreoffice.org/56047
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
When installing an extension e.g., paths can get very long and they
hit the 255 char limit, thus the installation fails.
So we need to prefix the path with the long file name prefix
when its longer than MAX_PATH for windows api calls to succeed.
Change-Id: Ie62644192ba40a9d4802772cd9837fc84fae947a
Reviewed-on: https://gerrit.libreoffice.org/50079
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 50bf4eec6ff3cb3db23484331965f2e32cb0b5bc)
Reviewed-on: https://gerrit.libreoffice.org/50228
|
|
Change-Id: If986352478f34f54015f1969c97c26e2ef05c06c
Reviewed-on: https://gerrit.libreoffice.org/49445
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... to already open soffice process from newly spawned one on Windows.
When an application takes user input, a timeout is started during
which other processes cannot create foreground windows that might
steal focus, and thus interrupt user input. The timeout is defined
by SPI_SETFOREGROUNDLOCKTIMEOUT (see SystemParametersInfo) and
ForegroundLockTimeout registry setting (see
https://technet.microsoft.com/en-us/library/cc957208). If an
application that currently doesn't have right to become foreground
tries to show popups in this interval, the popup will stay on
background, and only flash in taskbar.
The application that has the right to steal focus (see the list in
https://msdn.microsoft.com/en-us/library/ms632668) may transfer its
right to another process using AllowSetForegroundWindow function.
So, the intended effect is this:
1. User interacts with some foreground process (e.g., Explorer);
a timeout is started to prevent non-privileged processes from
stealing focus;
2. As the result, the process launches a new soffice process, which
has privilege to create foreground windows (as it is started by
foreground process);
3. It communicates with already started soffice process, which is
currently in background, and so doesn't have privilege to create
foreground windows until timeout expires;
4. It transfers its right to the already started soffice process,
and then issues the required commands that might lead to need to
show popup windows.
Change-Id: I4208665c2ae4106fa06e72269f4c3804af40d582
Reviewed-on: https://gerrit.libreoffice.org/48839
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 8d1d82dd63eada8faa2f6eb43ef900764a5fda62)
Reviewed-on: https://gerrit.libreoffice.org/48853
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Because of the odd non-standard rtl_digest_rawMD5() API that
is apparently necessary for MS Office interop, and there not
being any good reason for bug-compatibility here, just fix the bug.
Change-Id: Iaa0f0af4e24a5ddb9113c1ebd126f9822b5af1f6
(cherry picked from commit 18b022cadfa590df9dbefe0433b58838bcc3d2af)
Reviewed-on: https://gerrit.libreoffice.org/48019
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
so revert some of the changes from
commit 7a1c21e53fc4733a4bb52282ce0098fcc085ab0e
loplugin:simplifybool for negation of comparison operator
Change-Id: I937d575b86c1e418805d399b0dc16ae91876b4fe
Reviewed-on: https://gerrit.libreoffice.org/45130
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie56daf560185274754afbc7a09c432b5c2793791
Reviewed-on: https://gerrit.libreoffice.org/45068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3d0eb3bb6a69d09e71ce8bf91051f66e204eb0df
Reviewed-on: https://gerrit.libreoffice.org/45098
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...which had been left out because "lots of our code uses this style, which I'm
loathe to bulk-fix as yet", but now in
<https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have
caused an otherwise innocent-looking code change to trigger a
loplugin:unnecessaryparen warning for
pFormat = (pGrfObj)
? ...
(barring a change to ignoreAllImplicit in
compilerplugins/clang/unnecessaryparen.cxx similar to that in
<https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in
loplugin:simplifybool consistent", which should also have caused the warning to
disappear for the modified code, IIUC).
Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2
Reviewed-on: https://gerrit.libreoffice.org/45088
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This has big positive effect on software interpreter threading
performance scaling.
Change-Id: I8fbb6bf8f7ed410fd53278acee63bf65f13bac38
|
|
Change-Id: I40b3a46d46f0586d086bdbe41876c088f8c1cb58
Reviewed-on: https://gerrit.libreoffice.org/45007
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jens Carl <j.carl43@gmx.de>
|
|
Change-Id: I4f9b71ff7767e90987bb40358fc46ed5d1d571d0
Reviewed-on: https://gerrit.libreoffice.org/44944
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I677512213d97d01832bebe162fbf7de2998bf4d0
Reviewed-on: https://gerrit.libreoffice.org/44664
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Wuthout this fix, it had always tried to replace in original path,
thus second occurence of double path delimiter, like in
C:\dir1\\dir2\dir3\\file
would result in invalid path reported.
Change-Id: I63ce97b620229601e18f10016a759275aceeec4d
Reviewed-on: https://gerrit.libreoffice.org/44675
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ia544298334364ece3b3963a4adc00c5e01189b91
Reviewed-on: https://gerrit.libreoffice.org/44654
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Page <aptitude@btconnect.com>
|
|
...in code accidentally using auto like
> auto const aURL = uri->getUriReference() + "/"
> + INetURLObject::encode(
> m_sEmbeddedName, INetURLObject::PART_FPATH,
> INetURLObject::EncodeMechanism::All);
>
> uno::Reference<uno::XInterface> xDataSource(xDatabaseContext->getByName(aURL), uno::UNO_QUERY);
in <https://gerrit.libreoffice.org/#/c/44569/1> "Properly construct
vnd.sun.star.pkg URL" did (causing hard to debug test failures there).
So make functions taking O[U]StringConcat take those by rvalue reference.
Unfortunately, that also needed adaption of various functions that just forward
their arguments. And some code in sc/qa/unit/ucalc_formula.cxx used
CPPUNIT_ASSERT_EQUAL on OUStringConcat arguments in cases where that happened to
actually compile (because the structure of the two OUStringConcats was
identical), which needed adaption too (but which would arguably better use
CPPUNIT_ASSERT_EQUAL_MESSAGE, anyway).
Change-Id: I8994d932aaedb2a491c7c81c167e93379d4fb6e3
Reviewed-on: https://gerrit.libreoffice.org/44608
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0c356b100b732e259646d4ebb5d0aedd4dc4bcdd
Reviewed-on: https://gerrit.libreoffice.org/44302
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
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>
|
|
...between "error: unannotated fall-through between switch labels
[-Werror,-Wimplicit-fallthrough]" (in some builds, for the original code) and
"error: fallthrough annotation in unreachable code
[-Werror,-Wimplicit-fallthrough]" (in other builds, after adding
SAL_FALLTHROUGH).
Change-Id: I75bbefd69c81f43f22117f8ad110237de24e18af
|
|
Change-Id: I004bcba518ead9c149f1671d62aa94986a38945d
|
|
...after 0b413caadfbe68b278ca5ba33b6d204687586ea9 "loplugin:constantparam in
sal,sax"
Change-Id: Idf000bd1e0a261eac9ec0afbd2fb6f4c4ef8c7dc
|
|
...at least in com_GCC_class.mk (com_MSC_class.mk will be addressed in a follow-
up commit), after the recent loplugin:includeform clean-up.
Two static libraries built from external sources needed adjustment, two
compilerplugin tests needed adjustment (which wasn't found by
loplugin:includeform, by design), and one more adjustment in
sal/textenc/generate/.
Change-Id: Idad5ae355a02ae130369a9a45b5f5925ab48ffef
Reviewed-on: https://gerrit.libreoffice.org/44174
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7ca2fd05d1cf61f9038c529a853e72fedb1c9ed0
Reviewed-on: https://gerrit.libreoffice.org/44087
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ac99a6f470998364e9e43b749a0914d8a3fc096
Reviewed-on: https://gerrit.libreoffice.org/42769
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id60bcfadbfdf4b37f276159b12360347bde30a2e
|
|
...fixed similarly to recent fixes to sal/osl/unx/file.cxx
Change-Id: I2c82366095e156cd0085a8f60f54f8c822655dcc
|
|
(or does the comment need to go exactly at the line before the one containing
the "return" token?)
Change-Id: I5f92e59ee05d0b5ba3d6bda775e6ca02f185dbe8
|
|
with input 69e9223372036854775807
Change-Id: Iaf5a85170d144be2db5604340d784a8982754e08
Reviewed-on: https://gerrit.libreoffice.org/43815
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...in the one case where uOffset is of signed type sal_Int64
Change-Id: I626f747f70fb720bcc5a4ee10fbce30fc0673ae9
|
|
...as is reportedly the case for Linux AArch64
Change-Id: I7e11c42f4437c8aad9dd734603fa7e0d458c9754
|
|
Change-Id: Ic4d73e1fc328aecd897163b71edf0b4c9b8a090b
|
|
Change-Id: I935c5b4a219f3b673f62d8788504de85b53a47ca
|
|
Change-Id: I539ca8b9dee5edc5fc2282a2b9b0ffd78bad8b11
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
One of them was removed with
e6611cc2ef5960e9f32c56da44fafd02446f53e6, reintroduce to prevent
running into a dead end again.
16 or 17 digits will need some different approach.
Change-Id: Iec213ed857121e323e13ee83763c51fa563c794f
|
|
Change-Id: I68c42f6d9c6cfda90446a07ecd6bbf02abb22af9
Reviewed-on: https://gerrit.libreoffice.org/43593
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie75875974f054ff79bd64b1c261e79e2b78eb7fc
Reviewed-on: https://gerrit.libreoffice.org/43540
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... and munbers with few fractional bits
Change-Id: I86c3e8021e803fed498fae768ded9c9e5337c8bd
Reviewed-on: https://gerrit.libreoffice.org/43477
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
...in a way that, by using a function template, avoids new Clang 6
-Werror,-Wtautological-constant-compare when sal_Int64 and off_t are the same
type.
Change-Id: I06d4feb8ba8cb163e5208f107c28959755ff5633
|
|
Change-Id: I1ddd1f7d749a99395fbd7be433db5884536bf7a7
|
|
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b)
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>
|
|
The check for -userid switch has never worked - its condition was
broken since initial commit 9399c662f36c385b0c705eb34e636a9aec450282
Since this wasn't caught earlier, the functionality is unused
(and was deprecated anyway - see
https://wiki.openoffice.org/wiki/Framework/Article/Command_Line_Arguments),
this commit just drops the code.
Change-Id: Iae79f9cb7db454d72b11fb3954ebc456c7207d96
Reviewed-on: https://gerrit.libreoffice.org/43123
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ia632e4083222ad9e7f17c2ad0d0825f189c700cc
Reviewed-on: https://gerrit.libreoffice.org/43071
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7b68b70fa4c7234e8882f7627026959a596968fd
Reviewed-on: https://gerrit.libreoffice.org/43025
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
We should only use generic foo function name when it takes params
that are also dependent on UNICODE define, like
LoadCursor( nullptr, IDC_ARROW )
where IDC_ARROW is defined in MSVC headers synchronised with
LoadCursor definition.
We should always use Unicode API for any file paths operations,
because otherwise we will get "?" for any character in path that
is not in current non-unicode codepage, which will result in failed
file operations.
Change-Id: I3a7f453ca0f893002d8a9764318919709fd8b633
Reviewed-on: https://gerrit.libreoffice.org/42935
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iaa87663255f815e4f837df25d5338439d79c70dd
|
|
(probably because the encoding is RTL_TEXTENCODING_DONTKNOW; that may
still happen in various places, so can't use anything stronger than
SAL_WARN here)
Change-Id: I75993c9ad629104055c171389ed7708649747d9b
|
|
Change-Id: I9f54c8e8c4e617cc1ed6b436ca8c162d381ecab3
Reviewed-on: https://gerrit.libreoffice.org/42828
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4de6d9d781b2f2313d8fd338b34dcb31434efe91
Reviewed-on: https://gerrit.libreoffice.org/41638
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I879a52820d78d9151ef64dd21612379f617f66e2
Reviewed-on: https://gerrit.libreoffice.org/42726
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|