Re: Bug in Axis.CalcPosPoint (log scales)
Posted: Mon Jul 12, 2010 3:15 pm
Hi Narcis,
I have an addendum to my last posting:
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. And now I changed the formate string to "00e-0" (test4b.jpg): 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.
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
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.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:
I have an addendum to my last posting:
Me just encontered: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).
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. And now I changed the formate string to "00e-0" (test4b.jpg): 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.
Yes, that's a way. But please do not forget the exponential forms if you go this way!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?
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