The VAxisBase::m_xNumberFormatsSupplier refers to the ChartModel itself,
and apparently that is a cyclic reference. Naively using the
ChartModel's m_xNumberFormatsSupplier in
ChartView::impl_createDiagramAndContent() because it will later be passed
to AxisHelper::getExplicitNumberFormatKeyForAxis(), which expects to be
able to convert it to a ChartModel.
Since passing around the ChartModel as an XNumberFormattingSupplier is
sort of un-intuitive anyway, refactor some methods to use XChartDocument
instead, and only create the VPolarAxis / VCartesianAxis with the
ChartModel's m_xNumberFormatsSupplier.
The drawback is that if ChartModel::attachNumberFormatsSupplier()
is called after ChartView::update() has created the axes, it may not
have an effect on them; not sure if that is a real or hypothetical
problem.
Change-Id: Ib5f0d5882b85adaf44f80e086f19178b3e64882f
there were three of these, not just one
i.e. see also
commit 276a051ef5dc144a202633779259a4ecd43c81a8
Date: Sun Oct 5 13:05:04 2014 -0500
coverity#1223085 Unchecked return value
Change-Id: I07ee033ae31a346a08f68a6edfa480505fe6c11a
* 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>
...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>
In commit 88a874fc "convert SfxItemState constants to a proper enum"
I made some mistakes in converting bitwise logic to boolean logic.
I fixed one of those places in commit 7ad83656 "fix bitwise->logic
conversion in SfxItemState commit"
This commit fixes the other places where I converted bitwise to normal
boolean logic. I also validated that none of the existing code tries to
uses combinations of these enum values.
This commit also introduces an exception-throwing check in the one place
where the enum is explicitly cast to make sure that no combinations
sneak in.
Change-Id: I545f7d17b76c4fd999078867caec314e83ffe165
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I7f2348d82c76f6f231e34f0dfc4b6ee6fddffe55
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: If26ab3229871d2d6a7e4e7e8f79f4cb927b96930
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I3253b4cc5657a7d6b960ee892584109d373eed3d
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I3193eab34a34c051002adeedd8b368e26f55f7a3
Regression to master.
In long term it would be better to define ChartWindow as an
OpenGL window and not creating a new window inside the chart
window, becasue otherwise all events which was handled well
by the chart window will be broken (catched by the OpenGL
window so no effect on ChartWindow (defining the behavior of
charts in general) or catched by the ChartWindow and so no
effect on the OpenGLWindow (like invalidating in this case).
Change-Id: I234f469f70914e01f030c8edae9cb5aacea112bf
Problem after ChartWindow was disabled and enabled
again, OpenGL content was lost.
Two things:
-After setting a new OpenGLWindow the corresponding
IRenderer must be set (x3DWindowProvider->update)
-InitOpenGL() call should not depend on DummyChart, but on
OpenGLWindow (OpenGLContext).
Change-Id: If74e1945de9973d3921ceea1ca6fef39311add7a
...rather than an SfxInt32Item, just as it does everywhere else outside chart2.
At least, running CppunitTest_chart2_export under -fsanitize=undefined
complained about an invalid cast to SvxFrameDirectionItem.
Change-Id: Ia7ea43a00d659de9642f801f390f45b9239d9c32
...similar to what has been done for svx/sdtmfitm.hxx in
6a2ea81ca1622d2c2ad55bea8ddc28167fcc2794 "Remove unused ctors" and
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I6d8b3709d6d55bd6958d38f262141c43779dfdcc
Found by Lsan.
Returning this or a heap allocated object asks for trouble. Let the
caller handle it and return null instead of this.
Change-Id: I7586e103bef5a8c2727adfe214b052d6962d4467
Reviewed-on: https://gerrit.libreoffice.org/10716
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
and while we're at it
- use the enum type all over the place instead of passing around
sal_uInt16
- don't use bitwise logic on enum values
- use enum values instead of numeric constants
Change-Id: I7f24cb4d242e1c00703e7bbcf1a00c18ef1e9fd4
