forked from amazingfate/loongoffice
fd73aa7351
this story started in
commit 433fc2214c980abd82fa6240f45e634a53a3c61c (patch)
sal_uIntPtr->sal_Int32 in MultiSelection
which caused a regression, reported in tdf#116981.
I attempted to fix it in
commit 235d61890512894e27f4f81e38a325eee3c67b30
Date: Fri Apr 13 17:14:59 2018 +0200
tdf#116981 Base when deleting table column
and
commit 0973e1f4e727a3204c843398bcb0e6a411b1a02d
Date: Mon Apr 16 08:28:16 2018 +0200
follow on for tdf#116981
But my analysis was wrong.
To recap, and get it right:
Before all this, MultiSelection stored it's values internally as
sal_uIntPtr, but returned them as long in FirstSelected(),
NextSelected(),and SFX_ENDOFSELECTION was defined to be ULONG_MAX.
On 64-bit Linux, sal_uIntPtr is typedefed to sal_uInt64, and ULONG_MAX
is 2^64, which means that previously, the SFX_ENDOFSELECTION value was
being converted from 2^64 to -1 when it was returned, which was why
these loops worked.
So convert SFX_ENDOFSELECTION to -1 to match how how the external code
wants it to be (and the code frequently uses -1 instead of
SFX_ENDOFSELECTION or BROWSER_ENDOFSELECTION)
The modification to MultiSelection::Select is necessary because
previously, nCurMin and nCurMax would be == ULONG_MAX,
and we would, somewhat unintuitively, end up in the
// expand on left side?
if( nTmpMax < nCurMin )
part of the logic, which would do the right thing, even if a little
weirdly.
Change-Id: I7c830b0392add394d8c294247f75a2ffe8017c24
Reviewed-on: https://gerrit.libreoffice.org/53022
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>