there was two of these, see
commit 164bd64255d71d96e35e908f6425acf8372795fb
Date: Thu Oct 2 04:44:33 2014 -0500
coverity#1242757 Result is not floating-point
Change-Id: I1f66191f329b2d87bdeb52aa1a7528ca662064a6
* 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>
from PptSlidePersistList.
This also puts in assertions that every entry in a PptSlidePersistList
is non-null.
Cf. 9536a28ede89e8c29940e8ba225215a45667062c
Change-Id: Iea35532ed668e58a3f02d3f3433a66c2d4e1fe2a
Reviewed-on: https://gerrit.libreoffice.org/11807
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
ToolBarManager::Implementation::Update in sd/source/ui/view/ToolBarManager.cxx
is dubious. It takes its parameter by value (so in UnlockUpdate() the passed-in
mpSynchronousLayouterLock is reset upon passing it in), but the comment that it
"is [...] released at its end" together with the redundant
pLocalLayouterLock.reset() at the end of Update() make it look as though the
intention was to pass by reference. However, resetting
mpSynchronousLayouterLock even in the case where pass-by-ref would fail to reset
it is apparently important, as otherwise e.g. JunitTest_svx_unoapi would run
into the OSL_ASSERT(mpSynchronousLayouterLock.get()==NULL) in LockUpdate() with
a call stack of ... -> Update -> SetValid -> UpdateLockImplementation ->
LockUpdate.
Change-Id: I7d2717d5e1f8aa69c79a626c100d7fefb0cfb120
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
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
...to gain further confidence in the claim "that none of the existing
code tries to uses combinations of these enum values"
(d92602c5b13d0a60439d86c5a033d124178726ca "more fixes for SfxItemState")
Change-Id: I987922d945e8738e38adfde83b869adf3ff35b13
Reviewed-on: https://gerrit.libreoffice.org/11384
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
from ParagraphObj, by using boost::ptr_vector.
This is also a supposed fix for ParagraphObj::operator=(),
because ParagraphObj::ImplClear() now makes the vector empty
while its original code kept deleted pointers.
Change-Id: I7710eb33fc05bed55474ff00baaeb8e19cd79f3d
Reviewed-on: https://gerrit.libreoffice.org/11379
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
...similar to what has been done for svx/sdtmfitm.hxx in
6a2ea81ca1622d2c2ad55bea8ddc28167fcc2794 "Remove unused ctors" and
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I6d8b3709d6d55bd6958d38f262141c43779dfdcc
...similar to what has been done for svx/sdtmfitm.hxx in
6a2ea81ca1622d2c2ad55bea8ddc28167fcc2794 "Remove unused ctors" and
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: Ib0234883d441be668700df5ccd0e855973dc5426
...where some instances of SDRATTR_TEXT_MINFRAMEHEIGHT etc. where SdrMetricItem
while others where of trivial derived classes SdrTextMinFrameHeightItem etc.,
that appear to only existed for better-named constructors.
Change-Id: If0af79fbb803275ed09fc7b950868c5de7d61615
