Question about a couple of older versions

[Aaron Peronto]

We have been using the .NET versions of TeeChart for a few years now.
With a recent version of our application that we released we are seeing a significant difference in the points that are visible when a graph is drawn to the screen in our application.
The data is all present in the Series objects in the graph but when the graph is drawn with no lines but with symbols at the points visible (with a small size for the circle symbols) in an older version we can see more of the points without zooming in then we can in a new release.

The 2 versions that we are using are the following:

Older version: 3.2.2945.19738 from Jan 24 2008
Newer version: 3.5.3371.26406 from March 25 2009

With the Jan 2008 version on an unzoomed graph we see a full rendering of the points that are included in the data series on the graph.
With the March 2009 version on the same unzoomed graph in the same resolution setting we see places in the graph where data was previously visible with the older version but with the newer version it is not visible until you zoom in on the location where you know there should be data.

The graphs only contain 1954 total points each.

Did any rendering algorithms change for TeeChart or for the underlying OS level graphics calls possibly?

Our users were a bit concerned that data they could previously see is now no longer visible since we updated to a more recent version.

Thank you for any answers you can provide on this issue.

Aaron Peronto

[Narcís]

Hi Aaron,

Did any rendering algorithms change for TeeChart or for the underlying OS level graphics calls possibly?

Here you can read v3's release notes. You can see changes and bug fixes that have been implemented during this period. Some issues regarding points visibility were fixed but those occurred under very specific circumstances and it doesn't seem to be the case on your images.

Regarding the OS, I wouldn't expect any change as I would expect the .NET Framework handling this. Have you been able to reproduce this consistently in different environments?

If you have an example project with which we can reproduce the issue here we will be glad to investigate it.

Thanks in advance.

[Aaron Peronto]

We operate on a standardized platform on only the company maintained machines.
The results we are seeing are 100% reproducable on multiple machines with the versions noted.

Most likely, I will try to update the the very latest service release and see if we continue to see the same issues.
If we do, then I will probably try to take some time to generate data series exports and a sample app that I can send to you to reproduce this issue.

Thanks for the response.

Aaron

[Aaron Peronto]

I am doing a lot of investigation into this issue since our users have a lot of problem with the fact that there is data missing from our graphs.

It appears to be related to the TREATNULLS property.
The old version that we used to use was back when Series had the IGNORENULLS property and we set it to TRUE.

The way we use NULLS is we add points to the series and set them to NULL when we want the line to NOT be connected between 2 points.
**EDIT** Rewording this section so it is more clear and accurate to our process.
For example if we have a point at 8:00:00AM and the next valid data point is at 8:50:00AM.
We will add a NULL point with the same Y value but with the X 1 second after the 8:00:00 point (at 8:00:01).
This user to cause the graph to "pick-up the pen" and NOT draw the connecting line between the 2 points that are valid.

This worked in the old version that we used to use just fine.
Now, it seems that when we have points very close together and one is a NULL index, there are situations where even the valid point is not drawn.
I use the .TREATNULL property = .DoNotPaint. That seems to be the only setting that provides a similar function to the way we used to use NULLS.

This is a critical part of our application. We filter data and use the NULLs to indicate where the line should be broken.
When you turn off the LinePen.Visible property (using a Custom data series) and set the Pointer.Visible = true, we should get just the symbols drawn at the points that are NOT null. But we are seeing some of the points next to the NULL indexes not being drawn when the graph is fully unzoomed.
If you zoom in on the graph, the proper points are shown. So we know the data is in the series and recognized. But there is some problem with the display of the data.

If I change the TREATNULL property to Skip or Ignore, the points show up on the unzoomed graph properly but when the line is drawn it does not perform the way it used to. It draws the line between all the points and does not treat the NULL ones as breaks in the line any more.

I hope this makes some sense.
I am trying to produce a small test app to show this functionality to you first hand.

Any ideas? Recommendations? Better descriptions of how to use the TREATNULL property to accurately duplicate the way the IGNORENULL property used to work? The help documentation doesn't really help at all.

Thanks.
Aaron

[Aaron Peronto]

I have a sample app I will be emailing to the support address.
I will include in the email a link to this thread.

The problem seems to be with TreatNulls and the way we previously used the IgnoreNulls property.
When points are VERY close together, it seems that a NULL value is causing a good value to either not be drawn or be overwritten on screen with an empty point causing the display to not show the good value.

[Narcís]

Hi Aaron,

Have you sent the example project at the Pro-Support e-mail address? We haven't received it there. You can also attach projects to the forums posts now, below the text window or alternatively to our upload page.

Thanks in advance.

[Aaron Peronto]

I just sent it.
I attached it to a separate email since the first one had the project stripped off due to the size being too large for the Siemens Exhange Admin settings.
The project zip file was only 1MB or so and appears to have gone through from my side fine.

[Narcís]

Hi Aaron,

Thanks for the example project. After checking its implementation I think I have found the cause for this problem. When you loop through your series for setting null points (as in code snippet below) you are incrementing the loop variable twice at each iteration: one in the for loop and the other one just after the if statement. Commenting in second one (as in code below) works fine for me here as this made some points being skipped and therefore not being processed.

Code: Select all

            for (int i1a = 0; i1a < newS1A.Count; i1a++)
            {
                if (i1a > 0 && i1a < 100)
                {
                    newS1A.SetNull(i1a);
										newS1A.Add(newS1A[i1a].X - ONE_SECOND, newS1A[i1a].Y);
                    
                }
								//i1a++;
            }

I sent you modified Form1.cs with all “repeated increments” commented and which works fine for me here. Can you please check if this solves the problem at your end? If this is not what you expected from that project don’t hesitate to let us know.

[Aaron Peronto]

Like I said in the email response I made, looping through the data is NOT how we determine what is assigned as NULL.
This was done as a simple example and a way to put Null values into the series to show something similar to what we end up with after we filter our data and place the Nulls in where the data line should break.

If these values are being assigned as Nulls and you think that is why they don't show up in the fully unzoomed graph, then why do they show up when I zoom in?
Regardless of how the nulls are assigned and which values are assigned as null and which aren't.
Why is there data that is obviously there in the series and NOT visible in the fully unzoomed graph but become visible when you zoom in?

[Aaron Peronto]

Hi Aaron,

Thanks for the example project. After checking its implementation I think I have found the cause for this problem. When you loop through your series for setting null points (as in code snippet below) you are incrementing the loop variable twice at each iteration: one in the for loop and the other one just after the if statement. Commenting in second one (as in code below) works fine for me here as this made some points being skipped and therefore not being processed.

Code: Select all

            for (int i1a = 0; i1a < newS1A.Count; i1a++)
            {
                if (i1a > 0 && i1a < 100)
                {
                    newS1A.SetNull(i1a);
										newS1A.Add(newS1A[i1a].X - ONE_SECOND, newS1A[i1a].Y);
                    
                }
								//i1a++;
            }

I sent you modified Form1.cs with all “repeated increments” commented and which works fine for me here. Can you please check if this solves the problem at your end? If this is not what you expected from that project don’t hesitate to let us know.

I walked through the code with your changes.
My counter starts out at 1. I set the value at that index to be NULL using the SetNull() call.
I then insert a new item at 1 second prior to the X value of the one just set to NULL.
This value gets inserted at the index that is exactly the same as the one I jsut set to NULL. (1 in this example).
So I go back to the top of the loop and increment the counter once. This puts me at 2 which is now actually the value that I just set to NULL.
So I set it to null again and then add another value now at the index of 2.

So your version of the loop actually just inserts 99 items before what was originally the 2nd item in the array, all of which are set to NULL.
Once it gets to 100 for the index, it moves on to the rest of the data but doesn't insert any more NULLs.
So the problem of having good data values right next to the NULL set values does NOT happen in the example with the code change you've made.
So all of the data shows up fine because it is NOT in the same situation it was before.

The code change makes the data appear because it avoids the situation that is causing the problem in the first place I believe.

My original code actually accounts for the fact that the values that are getting inserted are being inserted at the index location that the loop was currently working on. My code will generate real, NON-NULL data points immediately next to NULL points in the array.

So I don't think this actually addresses the problem we are seeing.

[Narcís]

Hi Aaron,

Thanks for the information. I misunderstood what those additional points were intended for. I have added the issue to the bug list as a top priority item (TF02014437) to be investigated and fixed for next release.