BTW: the TAxisLabelChartSource the labels do not change when the window is increased because the chart size does not enter the calculation. This may be seen as an advantage (better controllability of label positions) or disadvantage (too sparse labels in case of large or even full-screen chart).
I guess we have three levels of automation now:
1. The build-in algorithm is fully automatic, number of labels, intervals etc. all is controlled by the algorithm, depending on data and size of chart. A custom manipulation is difficult.
2. Your algorithm which uses the StepCount as basis and does everything else automatic. Its easy adjustable to the data and gives more freedom for manual adjustment of the sizings in a simple way (using the StepCount).
3. My algorithm with manual set-up in the unzoomed state and full grid automation for zooming and panning. Therefore with more control of the grid in unzoomed state, but also more parameters needed.
I think in total having these three options is a very nice choice for the programmers! Do you see a chance (or advantage) to combine them in one class or would you rather keep it seperated? For the build-in one with options [aipUseCount,aipUseNiceSteps] I would actually expect a grid like calculated with your algorithm. For my algorithm in oposite I think its better to keep it separated as the parameters could get confusing.
On the otherhand using only the option [aipUseCount], then I would expect a behaviour like in my algorithm.
When I compared our two algorithms, I found that the use of StepCount is a bit different. In yours (we should really give them qualified names~) the StepCount is actually the minimum number of steps. When zooming, the actual step number may be the same or higher, but never less. In my implementation on the other hand for zooming its more like the avarage number, it could get lower and higher. I think both is reasonable, in my case the number is defined in the unzoomed state and when zooming, then in the first step the grid should get less. In your case the algorithm is quite nice using the minimum approach. For clearity it may be helpful to rename it to MinStepCount?
About the naming things: As I'm a 'new member' I hesitate with giving it a name, also its not so clear for me how to merge it into the TAChart component. Is there something like a standard procedure for such extensions/modifications? How to get 'agreement' from the developers?
Said that, here some proposals:
In my opinion the key difference in your algorithm in comparison to the built-in one is that the StepCount has to be defined, this makes it an interval chart source. As this class name already exists and this one is explicitly designed for an axis it could be Named TIntervalAxisSource.
For my algorithm it could be TManualIntervalAxisSource. But still FixedInterval is not that bad a name, I think, as it describes the function in the unzoomed state quite well.
About the StepCount/GridCount I still favour GridCount. In the TIntervalChartSource the parameter is just 'Count', especially derived in the TDateTimeIntervalChartSource its not so clear 'count' of what. I see it similar for StepCount: What 'steps'? Although its more precise if its for the number of intervals or number of grid bars, but when someone gets in touch with the parameter the first time, its more important to know what he can even influence with this parameter. IntervalCount might be an alternative.
Again about the parameters in my algorithm, in the current state, passing the bounds through AParams.FFullExtentMin doesn't work well, as the auto ranging will destroy the concept. If such parameters are used, then they should forward the explicit user settings in extent.XMin and Xmax (Because auto ranging is deemed as zooming). But this would cause trouble for Axis transformations. So I still think that dedicated parameters are more useful, even if its more difficult to understand the usage. Passing the extent on the other hand is also not very intuitive as the range also could be set in the axis parameters...
By the way, in the last two demos the manual bounds setting through the editboxes didn't work any more due to the auto ranging issue.