see can we silence these false positives
coverity#1240259 Operands don't affect result
coverity#1240254 Operands don't affect result
coverity#1240264 Operands don't affect result
coverity#1240267 Operands don't affect result
Change-Id: Ieca40474c231e33a516b70f7693346ac73babd61
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Move it's functionality into the only place that needs it, in the dbase
driver.
Removes an extra virtual call from a widely used class.
The dbase driver seems to be using to perform some kind of whacky object
recycling, so it's not like we want this functionality to be used
somewhere else.
Change-Id: I41018f71e0b0a79fdd3d527536f0ac95c788e614
Reviewed-on: https://gerrit.libreoffice.org/11786
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Put the TOOLS PolyPolygon class in the tools namespace. Avoids clash with the Windows
PolyPolygon typedef.
Change-Id: I811ecbb3d55ba4ce66e4555a8586f60fcd57fb66
left over from our conversion of the SvStream output operators
to more specific methods
e Please enter the commit message for your changes. Lines starting
Change-Id: Ibfe7635451ef7b8813d7a59c78c5223092a17ad5
- rename GUID to SvGUID so we don't need an #ifdef WIN32
- drop ClsId struct, since it is used interchangeably with GUID and has
the same structure
Change-Id: Idf5c14c82a6861ef585fb57896a9b12cfe40374c
Previously, the timer events could have accumulated in that scenario leading
to unresponsiveness to user events.
Change-Id: I455d726ae7475f7dbf98d871c54d8c156cb64e52
I introduce a template method into the PTR_CAST machinery
to maintain constness.
There is now a FIXME in sd/../docshell.cxx because I needed
to use a dynamic_cast there to work around the games it appears
to be playing with OLE in-place activation.
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>,
dropping the GCC-extension, unnecessary use of typeof from tools/rtti.hxx
Change-Id: Iba5ace1aa27e02b34fcc91af1e658c43371afd03
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
