X asix labels not lining up properly

[Captell]

thanks for the info Christopher.

I'm still a little confused, at some stage in the past this has actually worked, the post here http://www.teechart.net/support/viewtop ... 136#p47051 shows the chart with weekly data and the labels correctly aligned. I also know this has worked in the past because my clients running older versions of my product don't have this issue. I'm wondering if it might have been from an earlier version of teechart.

Can I ask why the need for the manually set offset. As I mentioned in the previous post the alignment works perfectly when monthly or Yearly data is used and the date values are either the first of the month for monthly or the first of the year for yearly. Why do we need this offset for weekly charts when the weekly dates are set to the first day of the week.

Finally, will this offset property be made available through the editor or must it be set in code?

Thanks Again.
Adrian.

[Christopher]

I'm still a little confused, at some stage in the past this has actually worked, the post here http://www.teechart.net/support/viewtop ... 136#p47051 shows the chart with weekly data and the labels correctly aligned. I also know this has worked in the past because my clients running older versions of my product don't have this issue. I'm wondering if it might have been from an earlier version of teechart.

As far as I know, this problem has existed in all past versions. Of course, a specific combination of bar numbers and chart width could spontaneously create axis labels at the right position.

If you want to absolutely guarantee that a specific point has a specific label independent of the size of the chart and the number of bars then the only way to do this is to add in point labels using the relevant Series.Add overload.

Can I ask why the need for the manually set offset. As I mentioned in the previous post the alignment works perfectly when monthly or Yearly data is used and the date values are either the first of the month for monthly or the first of the year for yearly. Why do we need this offset for weekly charts when the weekly dates are set to the first day of the week.

Yeray tried to explain this to you here: http://www.teechart.net/support/viewtop ... 136#p48256

TeeChart axes are agnostic as to the first day of the week. All TeeChart Axes understand are doubles. So when the interval is set to a week, the Axes understand that the interval is "7". Setting the first day of the week is similar, in effect, to setting the new IncrementOffset property.

Finally, will this offset property be made available through the editor or must it be set in code?

It will be able to be set through the editor and at runtime.

[Captell]

Thanks Christopher,

I'm downloading the new version now and will test it out during the day.

I understand that the axis only understands doubles and that setting an interval to one week effextively sets the interval to 7 but what I don't understand is how tchart determines the starting point of the axis, i.e. what is the first label. With monthly and yearly increments the first value used on the axis is the first value in the data however with weekly interval it seems the value is somewhat random. It seems to me that if tchart just used the first value in the data as the starting point then all would be well. This is how it seems to work for yearly and monthly intervals in bar series and for all increments in line and other series types.

Thanks again for your patience with me on this one, I really need ot understand how it all works as my applications primary function is to allow its users to use tchart to produce graphs.

Adrian.

[Captell]

Hi Christopher,
I've downloaded and installed the new build but unfortunately it doesn't really do any thing to resolve this issue.

My original chart with weekly increment set and data starting on 26Dec shows labels not aligned to bars

axis 1.png (17.75 KiB) Viewed 109467 times

If I change the new offset value to 4 the labels are aligned.

axis 2.png (27.79 KiB) Viewed 109462 times

However If I make the window just a tiny bit bigger then the labels are wrong again.

axis3.png (24.73 KiB) Viewed 109459 times

I really think the way to resolve this is the have tchart start the labeling with the first value from the data. so if the first date is 26Dec then the first label should be 26dec then the second label is 7 part the first etc.

[Christopher]

However If I make the window just a tiny bit bigger then the labels are wrong again.

Yes, that's right. That is what I meant when I said:

If you want to absolutely guarantee that a specific point has a specific label independent of the size of the chart and the number of bars then the only way to do this is to add in point labels using the relevant Series.Add overload.

Obviously the best way to understand how TeeChart processes axis labels is to read the source code. We sell a source code version of TeeChart, which I would recommend you buy. Other than that, you can use RedGate's Reflector to read the TeeChart.dll via reflection which you can download here http://www.red-gate.com/products/reflector/.

There are two ways that TeeChart renders axis labels:

• 1) Manually
  • a) Using Point Labels (Series.Add overload)
    b) Using Custom Labels (see Features Demo All Features\Welcome !\Axes\Labels\Custom labels )
  2) Automatically
  • a) Manual override of Increment (Axis.Increment)
    b) Manual override of Initial IncrementOffset (Axis.IncrementOffset)

When you let TeeChart render axis labels automatically, TeeChart calculates the size in pixels of the axis under which the labels are to be drawn and then based on this and the pixel width of the labels it calculates the value of the maximum axis label and the increment. It then loops backwards from the maximum label value drawing the labels with the calculated increment until no more labels fit on the axis. That is to say that when letting TeeChart render axis labels automatically, the value of the maximum label will ALWAYS depend on the pixel size of the axis. We can use the IncrementOffset to determine the maximum label value but this is only valid for a given range of pixel size of the axis in question.

The only way to guarantee that axis labels are drawn independently of the pixel size of the axis in question is to render the axis labels manually. In this way, TeeChart simply calculates the value on the axis at which the label is to be drawn (with point labels, the xvalue of the point, in custom labels the value is specified) and then draws them.

I hope this gives you a clearer idea of what is going on.

[Captell]

Thanks again Christopher,
I understand your explanation but if that is the case and if there are no bugs then one would expect the same behaviour to be present regardless of the series type. Consider the code and chart at the end of this post, it is exactly the same as the bar sample except with a line series, the labels align perfectly with the points.

In any event I can't help feeling that the basic design in this process (specifically for bars) is flawed. Considering the following image

06-08-2010 05-04-55.png (7.14 KiB) Viewed 109445 times

It shows the left most bar with a label of 27 Dec, all be it slightly misaligned but never the less the bar has a label showing the 27th Dec. This is plainly wrong as the true date for this bar is the 26th. This wouldn't be a problem so much if the series was a line series as line series are used to show continuous data. It's generally the shape of the entire line that is of interest and people understand that they must drop down from the point of interest on the line to the axis and infer what date it relates to. Bars are different in that they are used to show discrete observations with the label under the bar being (in our case) the date at which that discrete observation occured. Looking at the example above most (if not all) people would assume that the bar is for the 27th Dec when in fact it's for the 26th.

I am looking at ways I can get my application to automatically assign custom label values when an axis is Datetime and a standard increment has been set but I really think tchart should be doing this automatically.

Code: Select all

 Private Sub InitializeChart()
      TChart1.Clear()
      TChart1.Aspect.View3D = False

      Dim Line = New Steema.TeeChart.Styles.Line(TChart1.Chart)
      Line.XValues.DateTime = True


      TChart1.Axes.Bottom.Labels.Angle = 90
      TChart1.Axes.Bottom.Labels.DateTimeFormat = "yyyy-MM-dd ddd HH:mm:ss.fffffff"
      TChart1.Axes.Bottom.Increment = Utils.GetDateTimeStep(DateTimeSteps.OneWeek)

      Dim rnd = New Random
      Dim dte = New DateTime(2010, 8, 20, 0, 0, 0, 0)
      Dim y As Double
      For i As Integer = 0 To 9
         CType(Line, Steema.TeeChart.Styles.Line).Add(dte, rnd.[Next](100))
         dte = dte.Adddays(7)
      Next

   End Sub

produces the following chart

line1.png (40.59 KiB) Viewed 109449 times

[Christopher]

In any event I can't help feeling that the basic design in this process (specifically for bars) is flawed. Considering the following image

This is because Bar Point are not of zero width, whereas Line "points" are (virtually). Also the density of the labels in your two examples is widely different. You wouldn't be able to read the labels for their density to get the same effect with a Line series.

Believe me, the algorithms for calculating the maximum axis label value and increment are indentical. In fact, far better that you don't believe me and that you check it in the source code yourself!

Another way to understand the problem would be by scrolling the chart. Notice that there are times when the points (of the Line series, for example) coincide with the labels and other times when they do not. This becomes even clearer with bottom axis labels at an angle of 0 when the width of the label really begins to affect the algorithm. The only way to get the points and the labels to align under all circumstances, including scrolling and zooming, is to use manual axes labels.

What I'm not saying is that the design of TeeChart is perfect. What I am saying is that the present code conforms in a bug-free* manner to the present design paradigm with respect to automatic axes label calculations. We have a failsafe for such awkward cases built into the system which is to use manual axes labels.

*no known high-impact bugs

[Captell]

Ok accepted that everything conforms to the design paradigm but what about the situation in the example where the label under the bar is plainly wrong.

It shows the left most bar with a label of 27 Dec, all be it slightly misaligned but never the less the bar has a label showing the 27th Dec. This is plainly wrong as the true date for this bar is the 26th.

[Christopher]

Ok accepted that everything conforms to the design paradigm but what about the situation in the example where the label under the bar is plainly wrong.

It is *apparently* wrong, not plainly wrong . Think that the actual XValue of the Bar is the *middle* of the Bar. Following the *middle* of the Bar down to the bottom axis and extrpolating the value by eye, I would say that it probably does fall on the 26th. The label of the 27th clearly does *not* fall in the middle of the Bar and so is *not* the XValue the Bar represents.

[Captell]

It is *apparently* wrong, not plainly wrong . Think that the actual XValue of the Bar is the *middle* of the Bar. Following the *middle* of the Bar down to the bottom axis and extrpolating the value by eye, I would say that it probably does fall on the 26th. The label of the 27th clearly does *not* fall in the middle of the Bar and so is *not* the XValue the Bar represents.

I understand that but, the normal use of a bar chart is to look at the label at the bottom of the bar. Most users looking at the example will assume that the bar is for the 27th not the 26th, to expect them to know how the tchart labels work and that they should only take the label on face value if it falls exactly at the centre point bar is a bit of a stretch, don't you think?

[Christopher]

I understand that but, the normal use of a bar chart is to look at the label at the bottom of the bar. Most users looking at the example will assume that the bar is for the 27th not the 26th, to expect them to know how the tchart labels work and that they should only take the label on face value if it falls exactly at the centre point bar is a bit of a stretch, don't you think?

If that is your opinion that I would suggest that you either:

• 1) Use automatic axis labels in conjunction with series marks.
  2) Use manual axis labels.

[Captell]

Hi Christopher,
I'm trying to implement a solution to this issue using custom labels but am running into some more issues. Im using the following code

Code: Select all

Imports Steema.TeeChart.Styles
Imports Steema.TeeChart
Public Class Form1
   Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

   Public Sub New()
      MyBase.New()

      'This call is required by the Windows Form Designer.
      InitializeComponent()

      'Add any initialization after the InitializeComponent() call
      InitializeChart()
   End Sub

   'Form overrides dispose to clean up the component list.
   Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
      If disposing Then
         If Not (components Is Nothing) Then
            components.Dispose()
         End If
      End If
      MyBase.Dispose(disposing)
   End Sub

   'Required by the Windows Form Designer
   Private components As System.ComponentModel.IContainer

   'NOTE: The following procedure is required by the Windows Form Designer
   'It can be modified using the Windows Form Designer.  
   'Do not modify it using the code editor.
   Friend WithEvents TChart1 As Steema.TeeChart.TChart
   Friend WithEvents Button1 As System.Windows.Forms.Button
   Friend WithEvents btnRefresh As System.Windows.Forms.Button
   <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()
      Me.TChart1 = New Steema.TeeChart.TChart
      Me.Button1 = New System.Windows.Forms.Button
      Me.btnRefresh = New System.Windows.Forms.Button
      Me.SuspendLayout()
      '
      'TChart1
      '
      Me.TChart1.Dock = System.Windows.Forms.DockStyle.Top
      Me.TChart1.Location = New System.Drawing.Point(0, 0)
      Me.TChart1.Name = "TChart1"
      Me.TChart1.Size = New System.Drawing.Size(848, 600)
      Me.TChart1.TabIndex = 0
      '
      'Button1
      '
      Me.Button1.Location = New System.Drawing.Point(704, 616)
      Me.Button1.Name = "Button1"
      Me.Button1.Size = New System.Drawing.Size(120, 23)
      Me.Button1.TabIndex = 1
      Me.Button1.Text = "Edit"
      '
      'btnRefresh
      '
      Me.btnRefresh.Location = New System.Drawing.Point(560, 616)
      Me.btnRefresh.Name = "btnRefresh"
      Me.btnRefresh.Size = New System.Drawing.Size(120, 23)
      Me.btnRefresh.TabIndex = 2
      Me.btnRefresh.Text = "Refresh"
      '
      'Form1
      '
      Me.AutoScaleBaseSize = New System.Drawing.Size(5, 13)
      Me.ClientSize = New System.Drawing.Size(848, 654)
      Me.Controls.Add(Me.btnRefresh)
      Me.Controls.Add(Me.TChart1)
      Me.Controls.Add(Me.Button1)
      Me.Name = "Form1"
      Me.Text = "Form1"
      Me.ResumeLayout(False)

   End Sub

#End Region


   Private Sub InitializeChart()
      TChart1.Clear()
      TChart1.Aspect.View3D = False

      Dim bar = New Steema.TeeChart.Styles.Bar(TChart1.Chart)
      bar.XValues.DateTime = True


      TChart1.Axes.Bottom.Labels.Angle = 90
      TChart1.Axes.Bottom.Labels.DateTimeFormat = "ddd ddMMMyy"
      TChart1.Axes.Bottom.Increment = Utils.GetDateTimeStep(DateTimeSteps.OneWeek)

      Dim rnd = New Random
      Dim dte = New DateTime(2010, 8, 20, 0, 0, 0, 0)
      Dim y As Double
      For i As Integer = 0 To 20
         CType(bar, Steema.TeeChart.Styles.Bar).Add(dte, rnd.[Next](100), CDate(dte).ToString("ddd ddMMMyy"))
         dte = dte.Adddays(7)
      Next

   End Sub

   Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
      TChart1.ShowEditor()
   End Sub

   Private Sub btnRefresh_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnRefresh.Click
      InitializeChart()
   End Sub
End Class

which results in the following chart

weekly.png (52.26 KiB) Viewed 109423 times

which on the face of is seems to resolve my problem however if I resize the window slightly with the mouse I get the following

weekly2.png (50.08 KiB) Viewed 109416 times

Most of the labels dissapear. I'm really hoping to be able to resolve this issue this week by using something simmilar to the sample code, I'll just detect whether the axis is datetime and if so apply custom formatting. It should all work correctly apart from this strange behaviour when resizing. The problem also sometimes appears when the chart is first displayed, i.e. without first resizing.

Any suggestions.

Adrian.

[Captell]

A little more information, The problem with the dissapearing labels only seems to occur if there are 15 or more bars, less than 15 bars and the problem dosen't appear.

Thanks.

[Yeray]

Hi Captell,

Since you are adding the points with label, and you are showing it in the Bottom axis, you don't need to set any Increment and you won't probably need to add the points with XValue.
This works fine for me here:

Code: Select all

            tChart1.Aspect.View3D = false;

            Steema.TeeChart.Styles.Bar bar = new Steema.TeeChart.Styles.Bar(tChart1.Chart);
            bar.XValues.DateTime = true;

            tChart1.Axes.Bottom.Labels.Angle = 90;
            tChart1.Axes.Bottom.Labels.DateTimeFormat = "ddd ddMMMyy";
            //tChart1.Axes.Bottom.Increment = Steema.TeeChart.Utils.GetDateTimeStep(Steema.TeeChart.DateTimeSteps.OneWeek);

            Random rnd = new Random();
            DateTime dte = new DateTime(2010, 8, 20, 0, 0, 0, 0);
            for (int i = 0; i < 20; i++)
			{
                //bar.Add(dte, rnd.Next(100), dte.ToString("ddd ddMMMyy"));
                bar.Add(rnd.Next(100), dte.ToString("ddd ddMMMyy"));
                dte = dte.AddDays(7);
			}

However I think adding the points with DateTime XValue shouldn't cause problems here. I've added it to be investigated for future releases (TF02015083).

[Captell]

Thanks Yeray,
My application allows the user to use the chart editor to set properties on axes and other stuff in the chart. They also get to set what data is plotted, i.e. they set up their own database queries and then chart the resultant data. As the "problem" with the axes lables not lining up on bar charts is forcing me to manually add the labels I think don't think we can ignore the increment setting.

Since you are adding the points with label, and you are showing it in the Bottom axis, you don't need to set any Increment and you won't probably need to add the points with XValue.

The users will naturally set the increment when they create a bar chart, just like they do when they create a line chart. Can this be added to the list of things to look at please. I'd also like to see these issues looked at with some degree of urgency. At the moment I have users creating bar charts where the label under the bar (ok not directly centered under the bar but never the less under the bar) is not the actual date of the data represented by the bar.