parsing 1000s of line of code is hard enough without having to fight
with weird indentation and irregular formatting.
So as the review progress, in order to follow the code, cosmetic changes
were made...
In order to minimize the task of the reviewers and allow them to
concentrate on what matter, an effort is made to collect these
cosmetic changes into this separate commit.
Change-Id: I3c9b04a0150d0d0a048c2e976fe24de4f2b6b98a
the intent of this header has canged over time. now it is already
systematically included with ustring.hxx and the operator overload it
provide fit nicely there...
Just to be safe, since that include as been added to the api during the
3.5 timeframe and therefore is already in 'production'
the header remain and simply attempt to include ustring.hxx
but a warning is issued indicating that this header should not be used
anymore... in a couple of major release we will thenr emove it completely
All internal users of that header are converted.
Change-Id: I8934c55f089e29d78c0f5649b7c87b2ecf024bad
Reviewed-on: https://gerrit.libreoffice.org/634
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Looks like a regression from 4d949990ef1438fcae98262519c6af2b47e5ccf5 where for
every other case we did...
- XubString aRes;
+ ::rtl::OUString aRes;
aTmp.eType = SbxSTRING;
- aTmp.pString = &aRes;
+ aTmp.pOUString = &aRes;
while for this case we did only...
SbxValues aTmp;
XubString aRes;
aTmp.eType = SbxSTRING;
- aTmp.pString = &aRes;
Change-Id: I106cfbcc0fc0b27a9adcbb243d0d69c65b167005
Post commit 9df90559d40f029479c4481e31f88737b70742f6 we have problems where Date types are added and subtracted. In fact that commit makes a subset of numberic operation return the date type. This fix ensures that the Date type is only applied when processing '+' ( old behaviour broken by the commit above ) and '-' ( new behaviour for consistency ) If both LHS & RHS are Date types then the result of the operations in question return the Double type.
