Pre loader

MouseWheelZoomModifier syncs between different charts despite not sharing MouseEventyGroup Id

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

0
0

I have two separate view models each representing a chart pane. I explicitly do not share the MouseEventGroup Id, and expected none of the ChartModifiers to be shared. However, the MouseWheelZoomModifier is shared. When I zoom via mouse wheel on one chart the other chart is zoomed instantaneously as well. Visible Range is shared but what bothers me is that MouseWheelZoomModifier syncs but other modifiers do not. Is that intended? Desired is to not have any modifiers sync unless I share an identical MouseEventGroup Id.

Here is the code that produces this problem:

<s:SciChartSurface
                x:Name ="Surface"
                Padding="5"
                YAxes="{Binding YAxes, Mode=OneWay}"
                RenderableSeries="{s:SeriesBinding ChartSeries}"
                s:SciChartGroup.VerticalChartGroup="{Binding VerticalChartGroupId}"
                s:ThemeManager.Theme = "{Binding ChartTheme}">

        <s:SciChartSurface.Style>
            <Style TargetType="{x:Type s:SciChartSurface}">
                <Style.Triggers>
                    <!-- Enable DirectX only when not in designer -->
                    <Trigger Property="componentModel:DesignerProperties.IsInDesignMode" Value="False">
                        <Setter Property="s3D:DirectXHelper.TryApplyDirectXRenderer" Value="True" />
                        <Setter Property="s3D:DirectXHelper.FallbackType" Value="{x:Type s:HighQualityRenderSurface}" />
                    </Trigger>
                </Style.Triggers>
            </Style>
        </s:SciChartSurface.Style>

        <s:SciChartSurface.XAxis>
            <s:CategoryDateTimeAxis Id="XAxisId" Visibility="Visible" AutoRange="Never" GrowBy="0.01, 0.01" VisibleRange="{Binding XAxisVisibleRange, Mode=TwoWay}" VisibleRangeLimitMode="MinMax" LabelProvider="{Binding LabelProvider}"/>
        </s:SciChartSurface.XAxis>

        <s:SciChartSurface.ChartModifier>
            <s:ModifierGroup>

                <!--s:MouseManager.MouseEventGroup="{Binding SharedMouseGroupId}"-->

                <s:CursorModifier ReceiveHandledEvents="True" SourceMode="AllSeries" UseInterpolation="True" ShowAxisLabels="True" ShowTooltip="False"/>
                <s:ZoomPanModifier ReceiveHandledEvents="True" ZoomExtentsY="False" XyDirection="XDirection" ClipModeX ="ClipAtExtents" ExecuteOn ="MouseLeftButton" />
                <s:RubberBandXyZoomModifier ReceiveHandledEvents="True" IsAnimated = "False" IsXAxisOnly = "True" ExecuteOn = "MouseRightButton"/>
                <s:MouseWheelZoomModifier ReceiveHandledEvents="True" XyDirection = "XDirection"/>
                <s:ZoomExtentsModifier ReceiveHandledEvents="True" IsAnimated = "False" ExecuteOn = "MouseDoubleClick"/>
                <s:RolloverModifier ReceiveHandledEvents="True" x:Name="RollOverModifier" DrawVerticalLine="False" ShowTooltipOn="Never" SourceMode="AllSeries"/>

            </s:ModifierGroup>
        </s:SciChartSurface.ChartModifier>

    </s:SciChartSurface>

Edit:

In addition, I am having an issue with the following as well: I use an x-Axis Visible Range property in the the view model, that serves as data context to the rendering surface, I noticed the following issue: MouseWheelZoomModifier causes “_xAxisVisibleRange != value” inside the property setter to ALWAYS evaluate false even when zooming in and out with the mouse wheel. All other chart modifiers cause the inequality to evaluate true when the visible range changes due to applying the chart modifiers. A workaround would be to instead test for “_xAxisVisibleRange.Min != value.Min || _xAxisVisibleRange.Max != value.Max” but it is nonetheless an inconsistency.

Please see below code snippet to illustrate the issue:

public IRange XAxisVisibleRange
    {
        get { return _xAxisVisibleRange; }
        set
        {
            //this is only invoked by its own pane view model (never by an outside pane view model)
            if (_xAxisVisibleRange != value)
            {
                _xAxisVisibleRange = value;
                RaisePropertyChanged("XAxisVisibleRange");


            }
        }
    }
Version
5.3.0.11954
  • You must to post comments
0
0

Hi Matt,

The MouseManager.MouseEventGroup shares mouse and touch events across charts, however that won’t stop two charts from updating in unison if you also bind & share VisibleRanges across charts.

Which VisibleRange did you share? Both X and Y or just X ?

If you share XAxis.VisibleRange through some kind of TwoWay binding to a common IRange then it doesnt matter what modifiers or mouseeventgroup you have on the charts, the XAxis.VisibleRange will be shared in unison.

Best regards,
Andrew

  • bbmat
    @Andrew, you may have misunderstood my point. My question was about the inconsistency between chart modifiers how they behave differently when either using a MouseEventGroup Id and/or syncing the VisibleRange. In my above post I share the x-Axis Visible Range. Without using a shared MouseEventGroupId but sharing the VisibleRange the MouseWheelZoomModifier works but other chart modifiers don’t. On the other hand, when not sharing the VisibleRange at all, but sharing the MouseEventGroupId, synced panning does not work at all, but all other chart modifiers work. What is up with this inconsistency? It forces me to implement a lot of workarounds which consume precious latency.
  • bbmat
    @Andrew, please also see the EDIT in my post, another issue is that MouseWheelZoomModifier never causes x-Axis VisibleRange property to change inside the view model, while other chart modifiers do. I explained the issue in more details in above edit. Those issues very much look like bugs to me that got carried forward throughout the versions. Could you please have someone look into this in more detail because it really causes a lot of issues and workarounds that cost precious performance.
  • Andrew Burnett-Thompson
    Hi Matt, going through my email now reducing from 200 unread to near zero … Any time someone reports a bug, unless you give us code to repro or steps to repro, we can’t work on it. Simply that we have too many requests to spend time trying to reproduce them all. If you can supply us with steps or code to repro, please do – send a support ticket with the project or solution and we will gladly investigate. Best regards, Andrew
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.

Try SciChart Today

Start a trial and discover why we are the choice
of demanding developers worldwide

Start TrialCase Studies