Steema Issues Database

Note: This database is for bugs and wishes only. For technical support help, if you are a customer please visit our online forums;
otherwise you can use StackOverflow.
Before using this bug-tracker we recommend a look at this document, Steema Bug Fixing Policy.



Bug 2237 - FastLineSeries successfully cleared in RADstudio 10.1 Berlin, BROKEN in 10.3 Rio
Summary: FastLineSeries successfully cleared in RADstudio 10.1 Berlin, BROKEN in 10.3 Rio
Status: RESOLVED FIXED
Alias: None
Product: VCL TeeChart
Classification: Unclassified
Component: Series (show other bugs)
Version: 26.181203
Hardware: PC Windows
: High major
Target Milestone: ---
Assignee: Steema Issue Manager
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-10 09:51 EDT by Bill Anderson
Modified: 2019-10-11 04:07 EDT (History)
1 user (show)

See Also:
Chart Series: FastLine
Delphi / C++ Builder RAD IDE Version: RAD 10.3 Rio


Attachments
A picture showing the incorrect initial diagonal plotting (1.61 KB, image/png)
2019-09-10 09:51 EDT, Bill Anderson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Anderson 2019-09-10 09:51:18 EDT
Created attachment 919 [details]
A picture showing the incorrect initial diagonal plotting

When this code was run with Rad Studio 10.1 Berlin and TeeChart Pro VCL 2016.18 the following code below cleared the graph perfectly.

However, when I upgraded to Rad Studio 10.3 Rio and TeeChart Pro VCL 2019 (2018.26.18) this SAME code FAILED to clear correctly. Instead the plot started at the UPPER LEFT CORNER OF THE TCHART (on the chart, off the gaph) and then a line (red arrow) DIAGONALLY plotted to 0.0,0.0 origin in the graph.  It then continued to plot the first part of the sweep correctly (see graph).  The plotting obviously should have started plotting at the 0.0,0.0 origin in the graph like it did in 10.1 Berlin.

It seems likely to me that the Clear() function was working in Rad Studio 10.1 Berlin and TeeChart Pro 2016.18, and then failed in Rad Studio 10.3 Rio and TeeChart Pro 2019 (2018.26.18).

Has this BUG been found before, and if so, has it been fixed.  It seems like such a large bug that it couldn't have been missed.

Thank you for your help.

Sincerely,
Bill Anderson
Comment 1 Bill Anderson 2019-09-10 10:01:44 EDT
Here is the code where the bug occurs:

Code called FIRST to clear the several FastLineSeries in the graph
void Clear_GraphDataWindow(void)
  {
  TChart_FastLineSeries_RawArray->Clear();      // FIRST CLEAR FLSeries_RawArray
  TChart_FastLineSeries_BlankedArray->Clear();      // clear other FLSeries
  TChart_FastLineSeries_FilteredArray->Clear();     // clear other FLSeries
  TChart_FastLineSeries_AveragedArray->Clear();     // clear other FLSeries
  TChart->Refresh();
  }

Code called SECOND to clear and then plot only the FastLineSeries_RawArray
void Plot_PartOfLinearArray(unsigned long   FirstPlotSampleNum,
                            unsigned long   LastPlotSampleNum)
  {
  unsigned long  xx;

  if (FirstPlotSampleNum == 0)                     // if first time thru
    {
    TChart_FastLineSeries_RawArray->Clear(); // FAILS clear FLSeries before plot
    if (TChart_FastLineSeries_RawArray->XValues->Order == loAscending )
      TChart_FastLineSeries_RawArray->XValues->Order = loNone;
    }
  if ( TChart_FastLineSeries_RawArray->Color != clBlue )
    TChart_FastLineSeries_RawArray->Color = clBlue;
  TChart_FastLineSeries_RawArray->AutoRepaint = false;    // AutoRepaint false

  for (xx=FirstPlotSampleNum; xx <= LastPlotSampleNum; xx++)  // plot FLSeries
    {
    TChart_FastLineSeries_RawArray->AddXY((double)xx * dSampleIntveral,
                                          (double)ADarray[xx] * dADconvFactor,
                                          "",
                                          clBlue);
    }
  TChart_FastLineSeries_RawArray->AutoRepaint = true;  // AutoRepaint true
  }
Comment 2 marc meumann 2019-09-10 11:57:37 EDT
investigating
Comment 3 Bill Anderson 2019-09-13 09:22:59 EDT
(In reply to marc meumann from comment #2)
> investigating

Hi Marc,
Has there been any progress in determining what causes this bug?
Bill
Comment 4 marc meumann 2019-09-13 10:35:51 EDT
Hello Bill,

Built this quickly in Delphi as below; not sure if you consider it mimics your code closely enough.

I'll need to step back through older versions to see if there's any difference but this appears to work correctly with this sample data and the latest version of source. 

Running Clear_GraphDataWindow, then Plot_PartOfLinearArray. 

===============
procedure TForm13.Button1Click(Sender: TObject);
begin
  Clear_GraphDataWindow;
end;

procedure TForm13.Clear_GraphDataWindow;
begin
  Series1.Clear;      // FIRST CLEAR FLSeries_RawArray
  Series2.Clear;      // clear other FLSeries
  Series3.Clear;     // clear other FLSeries
  Series4.Clear;     // clear other FLSeries
  Chart1.Refresh;
end;

procedure TForm13.Button2Click(Sender: TObject);
begin
  Plot_PartOfLinearArray(0,100);
end;

procedure TForm13.FormCreate(Sender: TObject);
begin
  Series1.FillSampleValues(100);
  Series2.FillSampleValues(100);
  Series3.FillSampleValues(100);
  Series4.FillSampleValues(100);
end;

procedure TForm13.Plot_PartOfLinearArray(FirstPlotSampleNum,LastPlotSampleNum : Integer);
var xx, dSampleIntveral : Integer;
begin

  dSampleIntveral := 2;

  if (FirstPlotSampleNum = 0) then                  // if first time thru
  Begin

    Series1.Clear; // FAILS clear FLSeries before plot
    if (Series1.XValues.Order = loAscending ) then
      Series1.XValues.Order := loNone;

  End;
  if ( Series1.Color <> clBlue ) then
    Series1.Color := clBlue;
  Series1.AutoRepaint := False;    // AutoRepaint false

  for xx := FirstPlotSampleNum to LastPlotSampleNum-1 do  // plot FLSeries
  Begin
    //Series1.AddXY(xx * dSampleIntveral, ADarray[xx] * dADconvFactor, '', clBlue);
    Series1.AddXY(xx * dSampleIntveral, Random(100), '', clBlue);
  End;
  Series1.AutoRepaint := true;  // AutoRepaint true

end;
=========================

Regards,
Marc
Comment 5 Bill Anderson 2019-09-13 11:55:36 EDT
Hi Marc,

Thank you for getting your test program started.  A couple of thoughts:

1) I presume Series1 is a TFastLineSeries?

2) Try putting in a debugging breakpoint on the code
     Series1.AutoRepaint := true;
that is just after the line has been drawn by the loop containing Series1.AddXY(). This will stop the program just before the AutoRepaint starts again and hopefully before the diagonal line is erased.

3) Because I wanted to initially keep things simple, the diagonal line appears only after the PROGRAM IS STARTED (ie it is the VERY FIRST SWEEP/LINE IS DRAWN).

However, if there is a second sweep or line drawn, it will not draw the diagonal line but appears to initially draw a line from the right side of the graph (the maximum graph time - the last point of the previous sweep/line???) back to graph time 0 (the minimum graph time).

But to show this second line in a png picture is just not as obvious as the diagonal line, which sticks out like a sore thumb.

Thank you,
Bill
Comment 6 marc meumann 2019-09-16 11:43:33 EDT
Hello Bill,

Re 1. Yes, the series are FastLines.

Re 2. Yes, that helps show up a plot issue. A little different to your image as my test data is somewhat different I guess. There's a diagonal line plotted joining from (I'll need to check) what appears to be the last location before the clear to the new start location with the new data.

If I take out the Autorepaint code lines the 'join' plotline doesn't occur.

If I leave the AutoRepaint lines active and force a Chart paint before AutoRepaint:=False; (using Chart1.CopyToClipboardBitmap;) then that also cures the problem (a temporary workaround maybe). 

Re 3. In the case of my test application the line doesn't occur on startup but does occur when refreshing via Plot_PartOfLinearArray. In the case of your application it may be that the line is being plotted from the first pixel location (0,0) on startup.

This may all be due to the way FastLine plots (plotting pixel to pixel as data values change) and how AutoRepaint works. I'm not sure why the issue may have started to occur with a recent version of TeeChart, I wouldn't have expected changes here but will go and look for them.

Regards,
Marc
Comment 7 Bill Anderson 2019-09-16 13:02:45 EDT
Hi Marc,

So you have basically found a problem with TeeChart 2018 and Rio.  But the cause may not be a change from TeeChart 2016 to TeeChart 2018, but could be Embarcadero's fault when going from Berlin to Rio.


I am not sure you understood when I first see the problem.
> Re 3. In the case of my test application the line doesn't occur on startup but 
> does occur when refreshing via Plot_PartOfLinearArray.

Its not actually on startup, but is 

This may all be due to the way FastLine plots (plotting pixel to pixel as data values change) and how AutoRepaint works. I'm not sure why the issue may have started to occur with a recent version of TeeChart, I wouldn't have expected changes here but will go and look for them.



3) Because I wanted to initially keep things simple, the diagonal line appears only after the PROGRAM IS STARTED (ie it is the VERY FIRST SWEEP/LINE IS DRAWN).
Comment 8 Bill Anderson 2019-09-16 13:14:55 EDT
Hi Marc,

COMMENT 7 IS ALL SCREWED UP BECAUSE IT SOMEHOW GOT PUBLISHED BEFORE I HAD FINISHED WRITING IT.  THIS IS HOW IT SHOULD HAVE BEEN.


I'm glad you have found the same problem I saw with TeeChart 2018 and Rio - so you don't think I am "off my trolley".

But the cause may not be a change from TeeChart 2016 to TeeChart 2018, but could be Embarcadero's fault when going from Berlin to Rio.  But the problem is there.


I am not sure you understood when I first saw the problem:
> Re 3. In the case of my test application the line doesn't occur on startup but 
> does occur when refreshing via Plot_PartOfLinearArray.

In my case, the problem didn't occur DURING startup, but it is seen on the VERY FIRST SWEEP/LINE DRAWN).


I hope there is a real fix rather than covering up the problem with a bitmap write - primarily because it would slow things down.

Sincerely,
Bill
Comment 9 Bill Anderson 2019-09-19 14:14:49 EDT
Hi Marc,

Has there been any progress in fixing this bug?  Or has the fix been shunted aside and is idle?  Do you have any idea when the fix will be available?

Or should I find another way of getting it fixed like "Priority Support"?  Its the last big Steema bug in this version of my program and I don't want to wait months to get it out.

I am not sure the "workaround" you suggested will work well because (as I understand it) there will always be a line being drawn before each sweep that would be visible at fast replotting of the graphs (say every 0.1 seconds).

Sincerely,
Bill
Comment 10 marc meumann 2019-09-19 14:34:02 EDT
Hello Bill,

This is on the priority list. It shouldn't take long to get to a conclusion on it. A quick question though, without the AutoRepaint on/off lines (which clears the issue here) .. does that markedly slow down your app?

Regards,
Marc
Comment 11 Bill Anderson 2019-09-20 02:46:28 EDT
Hi Marc,

Thank you for putting it on the priority list.

> without the AutoRepaint on/off lines (which clears the issue here) .. does that 
> markedly slow down your app?
Yes, AutoRepaint really speeds things up. Without AutoRepaint temporarily off, plotting is so slow it becomes unusable.

Cheers,
Bill
Comment 12 marc meumann 2019-09-20 09:56:10 EDT
Hello Bill,

Here's a codefix proposal. If you have TeeChart sourcecode you can add this to the FastLineSeries in the Series.pas (& VCLTee.Series.pas) unit.

=============
//declaration in FastLineSeries, public
Procedure Clear; override;

//implementation
procedure TFastLineSeries.Clear;
begin
  inherited;
  if (ParentChart <> nil) then
    With ParentChart,Canvas do
    begin
        OldX := GetVertAxis.PosAxis;
        OldY := GetHorizAxis.PosAxis;
        if View3D then MoveTo3D(OldX,OldY,MiddleZ)
                  else MoveTo(OldX,OldY);
    end;
end;
=============

The code largely explains itself, the intention being to position the Canvas point correctly, back at the start, when a clear takes place, so that the next plot (lineTo) starts from that position, not from the position of the last point before clear.

We'll keep this issue open whilst checks take place.

Regards,
Marc
Comment 13 Bill Anderson 2019-09-23 10:47:53 EDT
Hi Marc,

Thanks for the temporary fix.  

However, I do not have the version of TeeChart Pro VCL that comes with source code.

Furthermore, I am not by any stretch of the imagination a GURU and would appreciate preferably the *.obj files of Series.pas and VCLTee.Series.pas and where to put them, or else detailed instructions of where to put the *.pas files and how to recompile them.

I do have RAD Studio, but I ALWAYS program in C++, NEVER Pascal. In fact I tried to downgrade my RAD Studio to just C++ Builder because I wanted to decrease the  annual support costs, but Embarcadero wouldn't let me do that.

I have Rad Studio 10.3 Rio and TeeChart Pro 2019 (2018.26.18).  Thank you.

Sincerely,
Bill
Comment 14 marc meumann 2019-09-23 11:51:07 EDT
Hello Bill,

We're working on finalising an update release now so expect to be able to ship the fix with the update version very soon.

Regards,
Marc