Internal Wt error with labels on chart

Added by Christophe Delépine over 1 year ago

Hello,

I have a WCartesianChart with a model containing 3 columns :
column 0 is X
column 1 is Y (1st serie drawn as lines)
column 2 is Y (2nd serie drawn as points)

i use the 2nd serie to display a red marker to show the selected point on the curve (non selected points are rendered as yellow markers in the 1st serie)

So in my case, for each X, there is always a value set in the model for column 1. However column 2 only has one value set.
It works ok.

However, if i enable labels for the 2nd serie, then i get a popup window from Wt (internal error) : see snapshot

Looks like a bug to me. Wt should check that the cell contains a value before trying to display the coordinates.

This is with today's git

Regards
Christophe


Replies

RE: Internal Wt error with labels on chart - Added by Wim Dumon over 1 year ago

Hello Christophe,

This is definitely not the intention. It's not immediately clear to me from the source code what the exact problem is. Could you make a small test case for it?

BR,
Wim.

RE: Internal Wt error with labels on chart - Added by Daniel Paull over 1 year ago

I'm seeing the same error often with my app, but I've not had time to look into the cause of the problem yet. However, I've made the following observation that might help... My page has five sliders on it and the range of some of the sliders is initially [0, 0]. The error is displayed when the page is loaded and the thumb for these sliders is not drawn. If I modify my code so that the sliders never have an empty range, then no error is displayed and the thumb is drawn.

Hopefully this is case repeatable at your end and it is the same problem as noted by Christophe.

Cheers,

Dan

RE: Internal Wt error with labels on chart - Added by Christophe Delépine about 1 year ago

Do something like this to reproduce the problem :

    model_ = new WStandardItemModel(0, 3);
    model_->insertRow(0);
    model_->setData(0, 0, boost::any(0));
    model_->setData(0, 1, boost::any(1));
    model_->setData(0, 2, boost::any());    <--- no value here intentionnally for the second series

    setModel(model_); 
    setXSeriesColumn(0);
    setLegendEnabled(false); 
    setType(ScatterPlot);

    WPen pen;
    pen.setColor(WColor(0, 0, 0, 100));
    pen.setWidth(1);

    WAxis& xAxis = axis(XAxis);
    WAxis& yAxis = axis(YAxis);
    xAxis.setLocation(ZeroValue);
    yAxis.setLocation(ZeroValue);

    xAxis.setLabelFormat("%.2f");
    yAxis.setLabelFormat("%.2f");
    xAxis.setLabelInterval(0.05);
    yAxis.setLabelInterval(0.05);
    xAxis.setRange(-0.1, 1.1);
    yAxis.setRange(-0.1, 1.2);
    xAxis.setGridLinesEnabled(true);
    yAxis.setGridLinesEnabled(true);
    xAxis.setGridLinesPen(pen);
    yAxis.setGridLinesPen(pen);

    setPlotAreaPadding(0, Left);
    setPlotAreaPadding(0, Right);
    setPlotAreaPadding(0, Bottom);
    setPlotAreaPadding(0, Top);

    setMargin(5, Top | Bottom);
    setMargin(WLength::Auto, Left | Right);
    setBackground(WBrush(WColor(150, 150, 150)));

    // Add the curves
    WDataSeries s(1, LineSeries);
    s.setShadow(WShadow(3, 3, WColor(0, 0, 0, 127), 2));
    s.setMarker(Chart::SquareMarker);
    s.setMarkerSize(4);
    s.setMarkerPen(WPen(WColor(0, 0, 0)));
    s.setMarkerBrush(WBrush(WColor(255, 255, 0)));
    s.setPen(WPen(WColor(0, 255, 0, 128)));

    //s.setLabelsEnabled(XAxis);
    //s.setLabelsEnabled(YAxis);
    addSeries(s);

    WDataSeries selection(2, PointSeries);
    selection.setMarker(Chart::SquareMarker);
    selection.setMarkerPen(WPen(WColor(0, 0, 0)));
    selection.setMarkerBrush(WBrush(WColor(255, 0, 0)));
    selection.setMarkerSize(5);
    selection.setLabelsEnabled(XAxis);
    selection.setLabelsEnabled(YAxis);   <--- this will cause the crash when the chart is rendered
    addSeries(selection);

RE: Internal Wt error with labels on chart - Added by Koen Deforche about 1 year ago

Hey Christophe,

I've found the problem with the test case -- thanks. I am not sure that this is also the cause for the first problem ?
I will push the fix to public git soon (hopefully by the end of the weekend).

Regards,
koen