thanks for your reply.
As I can see you are a programmer yourself, there's no need for me to beat around the
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.