Bug in Axis.CalcPosPoint (log scales)

[Uli]

Hi Narcis,

In that case, settings points to be null it would be a much easier workaround for you to implement. For performance reasons it would be more efficient setting X=0 points to null when adding them to the series, for example:

So it is not possible: The end users have to process experimental data of different origin (I don't mean the programm). At design time, I have no control whether the end user at run time wants to make a logarithmic scale or not. Additionally, this workaround requires to implement it in all classes of the application where series will be created, copied or converted, see my former message. But possibly one could change the color of the data points in the BeforeSeriesDraw event? Such an implementation would be a possibility since I could do it for the charts (mostly MDI childs). Then is not to much code to change. Do you see this possibility? But please take in mind: Even when the pointer is transparent line segments (if visible) will be drawn to invisible points (?), so it might be the same wrong result. And due to the bug with the changed legend behavior I have already big performance problems.

I have an addendum to my last posting:

I showed the axis labeling with "00e-0" three colleagues: they assumed "10e-6"as 1e-6 (they assumed it to be comparable to 10^-6).

Me just encontered:
In the next image (test4a.jpg) the label format is '#.0 "x10" E+0' (another preset offered by the chart editor). Here the Steema chart editor and the TChart interpretes it as
"10e-2" = 1e-2. (this is the correct value for the label near axis.bottom.maximum)
So I did, and my colleagues did, too.

test4a.jpg (87.42 KiB) Viewed 33926 times

And now I changed the formate string to "00e-0" (test4b.jpg):

test4b.JPG (53.55 KiB) Viewed 33924 times

It seems to be very clear: such ambiguity must be avoided.
So I really think labelling has to be enhanced. It's not consistent. Such behavior must lead to confused end users. End users sometimes tend to look not as sharp as required.

Having that in mind, how do you think such a feature should work? Adding a custom numeric format dialog for axis labels, as in the VCL version (see image below), would do the job?

Yes, that's a way. But please do not forget the exponential forms if you go this way!

Otherwise, with the current chart editor there are also possibilities, an example:
If the selected axis maximum is 1000 the chart editor may offer, for instance "####.#" and "####" and "#.0 "x10" E+0" or others, which are appropriate. Formate strings which are not appropriate for the current axis min/max values should not be shown. In this example this would be, for instance, "0e-0" since this formate string would lead to nonsense. And, as visualized with test4a.jpg and test4b.jpg, I assume "00e-0" as very dangerous and should not appear. Such an attempt, of course, would require that the list of formate strings must be dynamic and changed when the user selects another axis or upon axis scaling.

Best regards

Uli

[Narcís]

Hi Uli,

So it is not possible: The end users have to process experimental data of different origin (I don't mean the programm). At design time, I have no control whether the end user at run time wants to make a logarithmic scale or not. Additionally, this workaround requires to implement it in all classes of the application where series will be created, copied or converted, see my former message. But possibly one could change the color of the data points in the BeforeSeriesDraw event? Such an implementation would be a possibility since I could do it for the charts (mostly MDI childs). Then is not to much code to change. Do you see this possibility? But please take in mind: Even when the pointer is transparent line segments (if visible) will be drawn to invisible points (?), so it might be the same wrong result. And due to the bug with the changed legend behavior I have already big performance problems.

I'd use BeforeDrawValues, for example:

Code: Select all

        public Form1()
        {
            InitializeComponent();
            InitializeChart();
        }

        private void InitializeChart()
        {
            Steema.TeeChart.Styles.Line line1 = new Steema.TeeChart.Styles.Line(tChart1.Chart);

            line1.Pointer.Visible = true;
            line1.Add(0, 1e-5);
            line1.Add(0.1, 1e-5);
            line1.Add(0.2, 1e-6);
            line1.Add(0.3, 1e-7);
            line1.Add(0.4, 1e-8);

            tChart1.Axes.Left.Labels.ValueFormat = "0e-0";

            foreach (Steema.TeeChart.Styles.Series s in tChart1.Series)
            {
                s.BeforeDrawValues += new Steema.TeeChart.PaintChartEventHandler(s_BeforeDrawValues);
            }
        }

        void s_BeforeDrawValues(object sender, Steema.TeeChart.Drawing.Graphics3D g)
        {
            Steema.TeeChart.Styles.Series s = (Steema.TeeChart.Styles.Series)sender;

            for (int i = 0; i < s.Count; i++)
            {
                double tmp = s.XValues[i];

                if (tmp == 0)
                {
                    s.SetNull(i);
                }
                else
                {
                    if (tmp > 0.0) break; //By default s.XValues.Order = Steema.TeeChart.Styles.ValueListOrder.Ascending
                }
            }
        }

It seems to be very clear: such ambiguity must be avoided.
So I really think labelling has to be enhanced. It's not consistent. Such behavior must lead to confused end users. End users sometimes tend to look not as sharp as required.

So, do you mean that for consistency with ValueFormat = "#.0 \"x10\" E+0", "00e-0" should be replaced by "0e-0"?

Yes, that's a way. But please do not forget the exponential forms if you go this way!

Otherwise, with the current chart editor there are also possibilities, an example:
If the selected axis maximum is 1000 the chart editor may offer, for instance "####.#" and "####" and "#.0 "x10" E+0" or others, which are appropriate. Formate strings which are not appropriate for the current axis min/max values should not be shown. In this example this would be, for instance, "0e-0" since this formate string would lead to nonsense. And, as visualized with test4a.jpg and test4b.jpg, I assume "00e-0" as very dangerous and should not appear. Such an attempt, of course, would require that the list of formate strings must be dynamic and changed when the user selects another axis or upon axis scaling.

Ok, thanks for your feedback. I have added your request to the wish-list (TF02015024) to be considered for inclusion in future releases.

[Uli]

Hi Narcis,

concerning the previously here discussed other topic:

LC.exe was finished with error code - 1

I checked all the things described ind the tutorial, chapter 17, and these given in the links you provided in former posts: Finally, all them did not solve the problem. Possibly, deleting all (old) TeeCharts and adding new could solve the problem. But if you have of lot of them in the project (combined with events and special settings) this makes a lot of work and may lead to additional errors.

So I did this:
- Created new (empty) project/solution (same name as old solution)
- added TeeChart to form
- compiled and run (was OK)
- copied all classes of my application (including settings and resources) to the new solution folder
- added these classes to the project
- added missing references
- compiled and run (OK)

So it seems now to work. Possibly this can others help to save some time.

So, do you mean that for consistency with ValueFormat = "#.0 \"x10\" E+0", "00e-0" should be replaced by "0e-0"?

Yes, I think so.

I'd use BeforeDrawValues, for example:

Code: Select all

series.SetNull(i)

OK, that could work. Some questions:
- Will line segments be drawn to the transparent points?
- Is there a quick way to set it back (to transparency=0) when changing the scale back to linear?
- Have you checked the other case: What happens when y-axis is logarithmic and there are some points with y = 0?

Otherwise, with the current chart editor there are also possibilities, an example:
If the selected axis maximum is 1000 the chart editor may offer, for instance "####.#" and "####" and "#.0 "x10" E+0" or others, which are appropriate. Formate strings which are not appropriate for the current axis min/max values should not be shown. In this example this would be, for instance, "0e-0" since this formate string would lead to nonsense. And, as visualized with test4a.jpg and test4b.jpg, I assume "00e-0" as very dangerous and should not appear. Such an attempt, of course, would require that the list of formate strings must be dynamic and changed when the user selects another axis or upon axis scaling.

Ok, thanks for your feedback. I have added your request to the wish-list (TF02015024) to be considered for inclusion in future releases.

Before you have possibly implemented TF02015024:
For me it's important to protect end users to apply a wrong label formate. Can you provide access to the chart editors "values formate" combobox (at page labels/formate)? Then one could create more appropriate items for this combobox in dependence on the current data values. Additionally, adding a handler for the event occuring when selecting an axis in the chart editor would enhance the situation more.

Best regards

Uli

[Narcís]

Hi Uli,

So it seems now to work. Possibly this can others help to save some time.

Thanks for your feedback. I'm glad to hear you solved the issue.

Yes, I think so.

Ok, I have added your request to the wish-list (TF02015026) to be considered for inclusion in future releases.

OK, that could work. Some questions:
- Will line segments be drawn to the transparent points?

No. You may change this using the TreatNulls property but won't be painted by default.

- Is there a quick way to set it back (to transparency=0) when changing the scale back to linear?

Yes, setting point's color to Color.Empty as other points, for example:

Code: Select all

series.Colors[i] = Color.Empty;

- Have you checked the other case: What happens when y-axis is logarithmic and there are some points with y = 0?

Yes, same occurs with vertical axis. This a generic axis problem. Fixing this issue should fix both horizontal and vertical axes.

Before you have possibly implemented TF02015024:
For me it's important to protect end users to apply a wrong label formate. Can you provide access to the chart editors "values formate" combobox (at page labels/formate)? Then one could create more appropriate items for this combobox in dependence on the current data values. Additionally, adding a handler for the event occuring when selecting an axis in the chart editor would enhance the situation more.

I don't think it would be a very good idea implementing temporary solutions into TeeChart public versions. If you are a TeeChart for .NET 2010 source code customer you can make those changes at your end to fit your needs. I'd suggest you to use chart editor's CloseEditor event for that or also check ValueFormat after closing AxisEditor, for example:

Code: Select all

            Steema.TeeChart.Editors.AxisEditor axisEdit = new Steema.TeeChart.Editors.AxisEditor(tChart1.Axes.Bottom, null);
            axisEdit.ShowDialog(this);

            if (axisEdit.Axis.Labels.ValueFormat == "00e-0")
            {
                axisEdit.Axis.Labels.ValueFormat = "0e-0";
            }

[Uli]

Hallo Narcis,

thanks for the answer.

Code: Select all

                
Steema.TeeChart.Editors.AxisEditor axisEdit = new Steema.TeeChart.Editors.AxisEditor(tChart1.Axes.Bottom, null);
                axisEdit.ShowDialog(this);

                if (axisEdit.Axis.Labels.ValueFormat == "00e-0")
                {
                    axisEdit.Axis.Labels.ValueFormat = "0e-0";
                }

Yes, this is a workaround, but not a good one: Setting a (wrong) label formate int the editor is immediately applied to the chart. Changing it upon closing the editor may lead to confusion, too.

But is there really no possibility at my end? I think that I could use the Editor.ShowEditor event to modify the label formate strings in the values formate combobox. Or to edit the list with your presets? Is there a way to do this?

Best regards

Uli

[Narcís]

Hi Uli

But is there really no possibility at my end? I think that I could use the Editor.ShowEditor event to modify the label formate strings in the values formate combobox. Or to edit the list with your presets? Is there a way to do this?

No, I'm afraid you should modify Steema.TeeChart.Editors.EditorUtils.AddDefaultValueFormats method in EditorUtils.cs. You can use Red Gate's .NET reflector with TeeChart.dll to check AxisLabelsEditor implementation.

[Uli]

Hi Narcis,

thanks for the hint to .Net reflector. But as I understood this tool is only for analysis. So it's not possible to anything in EditorUtils.cs.

Best regards

Uli

[Narcís]

Hi Uli,

We have been investigating TF02015020 and TF02015021 further and here are our conclusions.

TF02015020. Nothing is drawn here:

Code: Select all

            tChart1.Aspect.View3D = false;
            tChart1.Axes.Bottom.Logarithmic = true;
            tChart1.Axes.Left.Logarithmic = true;

            Steema.TeeChart.Styles.Line line1 = new Steema.TeeChart.Styles.Line(tChart1.Chart);
            line1.Pointer.Visible = true;

            line1.Add(0, 100);
            line1.Add(1e-6, 10);
            line1.Add(1e-4, 54);
            line1.Add(1e-2, 70);

            //Workaround
            //tChart1.Axes.Bottom.AutomaticMinimum = false;
            //tChart1.Axes.Bottom.Minimum = 1e-6;

The reason is that since log(0) doesn't exist a minimum value needs to be set to the axis. Internally it's set to 0.1. Since all values in the dataset above are lower than 0.1 they are plotted outside the visible axis range. Therefore it is necessary setting a value for Axis.Minimum lower than 0.1. This is a corner case and we think it is the programmer responsibility to decide what to do when using log(0) in a logarithmic-scaled chart.

TF02015021. Points at X=0 may be plotted here because some margin is necessary to plot series pointers. Setting Series.Pointer.Visible to false doesn't display point at X=0. We suggest to set zero points to null here, as shown in the example below, so that they are not plotted.

Code: Select all

            tChart1.Aspect.View3D = false;
            tChart1.Axes.Bottom.Logarithmic = true;
            //tChart1.Axes.Left.Logarithmic = true;

            tChart1.Axes.Bottom.AutomaticMinimum = false;
            tChart1.Axes.Bottom.Minimum = 1e-9;

            Steema.TeeChart.Styles.Line line1 = new Steema.TeeChart.Styles.Line(tChart1.Chart);
            line1.Pointer.Visible = true;

            line1.Add(0, 1195990, Color.Transparent);
            line1.Add(3.486E-5, 1088321.18811881);
            line1.Add(6.937E-5, 935244.059405941);
            line1.Add(0.0001374, 681926.287128713);
            line1.Add(0.0002696, 312229.455445545);
            line1.Add(0.0004279, 125870.792079208);
            line1.Add(0.0006663, 54966.1881188119);
            line1.Add(0.001289, 28498.1435643564);
            line1.Add(0.003094, 18828.7871287129);
            line1.Add(0.00696, 16525.3712871287);
            line1.Add(0.0135, 15589.3811881188);
            line1.Add(0.02082, 16215.5693069307);

Doing several tests and thinking about possible solutions we reached the conclusion those are corner cases for which is not worth implementing specific logic into the components and it's better left to the programmer to decide what to do in such circumstances.

[Uli]

Hi Narcis,

I can not understand your point of view, and I can not accept it:

TF02015020 (...)
The reason is that since log(0) doesn't exist a minimum value needs to be set to the axis. Internally it's set to 0.1. Since all values in the dataset above are lower than 0.1 they are plotted outside the visible axis range. Therefore it is necessary setting a value for Axis.Minimum lower than 0.1. This is a corner case and we think it is the programmer responsibility to decide what to do when using log(0) in a logarithmic-scaled chart.

(1)
Automatic axis scaling has to work under all circumstances
So it's not a corner case, it's simply a bug!
(2)
log(0) must not be used! Only values > 0 should be plotted!
(3)
A fixed internal axis minimum of 0.1 is dumb (sorry), a lot of real world properties are far below (Nanometer, Picoseconds, Mikrojoule, Femtomole, for instance)
(4)
It's so easy to calculate an appropriate axis minimum: you only have to take the smallest point with x > 0 (or y > 0, respectively). I can't understand that this is not possible for STEEMA programmers!
(5)
And to put it in the programmers hand is not acceptable: The end user at run time is not a programmer. He has to work with the program and the chart editor without coming in trouble. And that is not possible. Do you assume it as fair to demand from your customers to build their own Axis editor? TeeChart is not cheap.

TF02015021. Points at X=0 may be plotted here because some margin is necessary to plot series pointers. Setting Series.Pointer.Visible to false doesn't display point at X=0. We suggest to set zero points to null here, as shown in the example below, so that they are not plotted.

Points at X=0 must not be plotted here. I can assume it as a temporary work around.

Doing several tests and thinking about possible solutions we reached the conclusion those are corner cases for which is not worth implementing specific logic into the components and it's better left to the programmer to decide what to do in such circumstances.

It's so easy to implement. In my former Delphi application with my self written chart control I did it (it still seems to be faster than TeeChart). But my main task is not to program an application: Main goal is to provide this application for me and others and to apply it to process and to present data. So I bought TeeChart in order to focus more on data evaluation and processing... Was it a wrong decision?

Does STEEMA stand for the quality of it's chart control ???

Best regards

Uli

[Christopher]

Hi,

I'm the lead dev on TeeChart for .NET. Nice to meet you

As I can see you are a programmer yourself, there's no need for me to beat around the bush.

Of course we could add the logic in to calculate the minimum non-zero value of the series. I made some tests which did exactly that. However, these tests led me to the conclusion that doing so adds unnecessary complexity to the code, with the additional performance and maintenance costs involved. This, together with the fact that the workaround is so trivial, even for a non-programmer, made me leave the code out. I discussed this with Narcís who relayed the information to you.

As you well know, a bug can be defined as code which does not function as designed. This is not the case with this issue. The code functions exactly as designed. So here we are discussing the validity of the design of the code and not the code itself.

My decision is not carved in stone and can be changed in a future version if deemed necessary. I'm sorry you seem to be so angry about it. Maybe you could give me some insight as to why you can't use the simply remedy of setting the axis minimum value manually in this particular instance.

[Uli]

Hi Christopher,

thanks for your reply.

As I can see you are a programmer yourself, there's no need for me to beat around the
bush.

No, I'm chemist. And as scientist I rely on precision, reproducibility and targetted functionality. My application under work shall fulfill these requirements. Main tasks / requirements are:
(1) reading experimental data from different sources
(2) import of my old file format
(3) processing data according to our requirements including enhanced data treatment like modeling or approximation
(4) ergonomic handling and unambiguity of presentation, good performance
(5) usability even for the potentially most stupid user
(6) publication-ready presentation of data
(7) trustworthiness (in accordance with the accepted principles of protection of good scientific practice)

My application will be used by, for instance, technicians, diploma and Ph.D. students. Their experience and ability to recognize a "wrong output" of experiments or data treatment by software differs. These circumstances I have to take into account before releasing the software. If instruments or software produce a wrong or ambiguous output users are sometimes not able to recognize that. And there are examples that such results occur in the literature, even in highly respected journals.

Now I will go to the concrete problem.

As you well know, a bug can be defined as code which does not function as designed. This is not the case with this issue. The code functions exactly as designed. So here we are discussing the validity of the design of the code and not the code itself.

I don't agree with you: From my point of view, correct auto scaling has to include the following:

(1) setting axis minimum, maximum and interval in accordance with the data to present
(2) unambiguous label formatting (preferably, it could be presentation ready)
(3) only points with values in the min/max range have to be displayed

The TeeChart code does not fulfill these requirements with respect to logarithmic axes. It's not imported for me whether it is by design or not. It is a bug in my eyes. If you say that is "by design" then - that is my view concerning trustworthy software - you have it to declare and to protect the user towards the possibility of presenting wrong data. And in your description and documentation of TeeChart I nothing read about this.

If I would implement it in the chart_beforedraw event I'm sure that it reduces the performance much more in comparison to the implementation in TeeChart code. Additionally, you have to take into account the end user. I mean the people working with the released application and the axis editor in order to process real world data: If I would implement something in the chart_beforedraw event the end user must be highly confused when he tries to format the axis chart editor and he does not get what he can expect (see point 5 of the above enumeration). This has to be seen in connection with the very wrong implementation of label format strings. One cannot demand that the user is familiar with the MS specifications of format strings. And here, I have no possibility to change anything without completely to exclude the axis editor from the project. So I can also not understand that STEEMA the things with the label format assumes as a topic of low priority. Nothing has been changed in the August release.

A further critical remark: [TF02014988] is declared as fixed for the new release. Has anyone at STEEMA done a deeper look on logarithmic (not only horizontal) axes with for instance negative exponents using the format string included in chart editor (and, I believe, suggested in tutorial or sample application)? Have you recognized that the midpoint of the labels is not under the tick? Have you tried to change "1.0*10^5" to "1*10^5" or to the more appropriate "10^5"? Possibly I will address this in another thread.

I feel that STEEMA does not pay the appropriate attention to the problems that prevent the use of my application for real work. There are several examples in the different threads originated by me.

Taking furthermore into account:
(1) I wrote my own legend since properties (necessary for my rich text implementation in legend items) in newer releases were not more available and workarounds did not lead to appropriate behavior (from my point of view it does not matter whether it is bug or feature change, in the help they are still included). The code could work with every canvas
(2) I still have realized rich text for axis title and annotations, see (1)
(3) When the next maintenance will come - can I believe that the issues will then be solved? The permanent existing logarithmic axis label and scaling problem creates some doubts.
(4) My data processing functions do not depend on TeeChart
(5) It would be nice to have the broad range of possibilities offered by TeeChart - if they work properly. And it would be nice to not have to work on this part of my application. But the whole range of TeeChart features is not necessary for me.
(6) I have my old properly working Delphi application
(7) I have no access to TeeChart source code and therefore no possibility to treat an issue by myself (That is intentionally, I wanted to have my hands free for the other tasks)

So automatically a number of question come to mind:

(1) Switching back to my old Delphi application: From several reasons my answer is "No", but it works sufficiently until I have the final solution (With the exception that in the new one I have implemented some extended or new functionality)

(2) Staying with current TeeChart based application? But due to the Teechart issues it is not yet acceptable for real world use. And when it will be?

(3) Using another chart control? Before I came to TeeChart I experimented with MSChart, and I still have the functionality to import my old file format as well as my instruments file. A reason to go to TeeChart were the editors. ZedGraph ? Or another commercial one?

(4) Writing my own chart control focused on my special requirements? I could use parts of my Delphi code, translated or as dll.

All of the alternatives have advantages and disadvantages. The most important factor for my decision should be the expected required time and effort to come to a properly working application which meets the requirements discussed above. In the moment I'm still looking for the best answer.

Best regards

Uli

[Christopher]

No, I'm chemist. And as scientist I rely on precision, reproducibility and targetted functionality.

That's cool. I'm a medical doctor. Just goes to show we can be more than one thing at the same time

I don't agree with you: From my point of view, correct auto scaling has to include the following:

I think you forget:
(4) only data which is mathematically real should be handled automatically. Log(0) is not a mathematical reality.

If you say that is "by design" then - that is my view concerning trustworthy software - you have it to declare and to protect the user towards the possibility of presenting wrong data.

TeeChart does not throw anything anywhere near an unhandled exception when non-real data (Log(0)) is added to the chart. What is more, getting TeeChart to handle non-mathematically real data in this instance is *one line of runtime code*.

One cannot demand that the user is familiar with the MS specifications of format strings.

Yes, one can. TeeChart for .NET runs in the Microsoft .NET Framework and so it is perfectly natural to expect people working in it to be familiar with MS specifications.

A further critical remark: [TF02014988] is declared as fixed for the new release. Has anyone at STEEMA done a deeper look on logarithmic (not only horizontal) axes with for instance negative exponents using the format string included in chart editor (and, I believe, suggested in tutorial or sample application)? Have you recognized that the midpoint of the labels is not under the tick? Have you tried to change "1.0*10^5" to "1*10^5" or to the more appropriate "10^5"? Possibly I will address this in another thread.

This is what [TF02014988] looks like in our database:
"There are a problem with axis scaling when you use exponent property scale of bottom axis, its position of labels is wrong."

To this extent this defect is fixed. If you feel that there are other defects associated with exponential axis labels, please do not hesitate to start another thread and we'll look at them.

All of the alternatives have advantages and disadvantages. The most important factor for my decision should be the expected required time and effort to come to a properly working application which meets the requirements discussed above. In the moment I'm still looking for the best answer.

It far from my responsibility to tell you how you should be developing your application. Obviously we would be very happy if you were to choose a TeeChart solution. TeeChart has been used in the real world for over 13 years. Have a look at the wikipedia article here http://en.wikipedia.org/wiki/Teechart.

TeeChart, like any piece of software, is not perfect. It has defects that we know about that have yet to be fixed and for sure it has defects that we don't know about yet. Buying a TeeChart control means buying a service which includes the fixing of defects as well as the modification of aspects of TeeChart's design paradigm to fit in with our client's needs. We are capable and willing to work with our clients to the best of our ability until our clients are happy with their purchase. Having tens of thousands of client does mean, however, that we cannot attend to any individual client's needs instantaneously.

I'm quite sure that we will be able to make you happy with your purchase of TeeChart. What I can't guarantee is when that will be. Please do start new threads for any new defects you have found and we will look at them and try to fix them in due course.

As far as the present issue is concerned, the handling of Log(0) values in a logarithmic chart, I'm quite happy with the way TeeChart works at the moment. As I have said, this doesn't mean that I have no intention of revising my position in the future as client needs arise. However, please be aware that today is my last day of work before my summer holidays. You'll have to forgive me if I don't give the issue any thought whatsoever in the next couple of weeks or so

[Uli]

Hi,

I think you forget:
(4) only data which is mathematically real should be handled automatically. Log(0) is not a mathematical reality.
...
TeeChart does not throw anything anywhere near an unhandled exception when non-real data (Log(0)) is added to the chart. What is more, getting TeeChart to handle non-mathematically real data in this instance is *one line of runtime code*.

That's not true: There is no data value with log(0) in the chart! So TeeChart has to handle all data points!!! Possibly you did not understand the problem?

One cannot demand that the user is familiar with the MS specifications of format strings.

Yes, one can. TeeChart for .NET runs in the Microsoft .NET Framework and so it is perfectly natural to expect people working in it to be familiar with MS specifications.

No. You can demand it from the programmer using your chart control, but you can't demand it from the end user working with the final application. He often will possibly never have heard anything about .NET. And when this end user works with Teechart editor no programmer can prevent him to do crazy things - only TeeChart code and his editor can do this. Possibly you have not really tried to understand my explanations?

This is what [TF02014988] looks like in our database:
"There are a problem with axis scaling when you use exponent property scale of bottom axis, its position of labels is wrong."

To this extent this defect is fixed. If you feel that there are other defects associated with exponential axis labels, please do not hesitate to start another thread and we'll look at them.

And even this issue is not really fixed. It should work with any valid format string, and it does not. It even works not correctly with this string included in the corresponding chart editor combobox. I think one can expect that after programming or fixing any object the programmer checks the full functionality of that object carefully. Here it was not done.

Regards

Uli

[Christopher]

That's not true: There is no data value with log(0) in the chart! So TeeChart has to handle all data points!!! Possibly you did not understand the problem?

What problem?

TeeChart handles the addition of non-real values (a data value of zero in a log chart) without throwing an exception. There is no problem here. However, as things stand, when the programmer adds in a zero value to a log chart, which he/she should know cannot be plotted, then we ask him/her to add in one extra line of code under some (not all) circumstances.

No. You can demand it from the programmer using your chart control, but you can't demand it from the end user working with the final application. He often will possibly never have heard anything about .NET. And when this end user works with Teechart editor no programmer can prevent him to do crazy things - only TeeChart code and his editor can do this. Possibly you have not really tried to understand my explanations?

I honestly can't see how accusing me of not understanding what you write is in any way helpful to this discussion.

The TeeChart Editor is designed to handle stopping the end user doing "crazy" things. What it isn't designed to do is to accept whatever the end user adds to it as valid input. At the moment, the TeeChart Editor handles the format strings that it does. If you would like it to handle some more, please give me an exhaustive list of the ones that you want it to handle.

And even this issue is not really fixed. It should work with any valid format string, and it does not. It even works not correctly with this string included in the corresponding chart editor combobox. I think one can expect that after programming or fixing any object the programmer checks the full functionality of that object carefully. Here it was not done.

It is obvious that what you and I consider as a valid format string are two different things. As I said above, if you'd like TeeChart to accept format strings other than the ones that TeeChart presently accepts, please post an exhaustive list here (or give us a URL to one).

[Christopher]

That's not true: There is no data value with log(0) in the chart! So TeeChart has to handle all data points!!! Possibly you did not understand the problem?

What problem?

TeeChart handles the addition of non-real values (a data value of zero in a log chart) without throwing an exception. There is no problem here. However, as things stand, when the programmer adds in a zero value to a log chart, which he/she should know cannot be plotted, then we ask him/her to add in one extra line of code under some (not all) circumstances.

No. You can demand it from the programmer using your chart control, but you can't demand it from the end user working with the final application. He often will possibly never have heard anything about .NET. And when this end user works with Teechart editor no programmer can prevent him to do crazy things - only TeeChart code and his editor can do this. Possibly you have not really tried to understand my explanations?

I honestly can't see how accusing me of not understanding what you write is in any way helpful to this discussion.

The TeeChart Editor is designed to handle stopping the end user doing "crazy" things. What it isn't designed to do is to accept whatever the end user adds to it as valid input. At the moment, the TeeChart Editor handles the format strings that it does. If you would like it to handle some more, please give us an exhaustive list of the ones that you want it to handle.

And even this issue is not really fixed. It should work with any valid format string, and it does not. It even works not correctly with this string included in the corresponding chart editor combobox. I think one can expect that after programming or fixing any object the programmer checks the full functionality of that object carefully. Here it was not done.

It is obvious that what you and I consider as a valid format string are two different things. As I said above, if you'd like TeeChart to accept format strings other than the ones that TeeChart presently accepts, please post an exhaustive list here (or give us a URL to one).