On Tue, 7 Nov 2017, Werner Pamler via Lazarus wrote:
Am 07.11.2017 um 13:42 schrieb Michael Van Canneyt via Lazarus:
I don't see why you would need a separate package. fpexprparser is in the
FCL since 10 years or so. A separate unit is definitely good so as to
minimize the dependencies of the basic tachart unit, but a package ?
Seems overkill to me ?
Maybe I am paranoid here or oversensitive because it has never been
clear to me whether "unused" code is linked into a program or not. When
there is designtime or initialization code "unused" code may be called
internally although it is never called explicitly by the program itself.
To be specific: How much of the otherwise unused fpexprparser is linked
into a program if the initialization code of the TExpressionSeries unit
adds the series to the list needed by the series editor at designtime?
Probably none, but I am not sure... Therefore I follow the strategy to
keep packages as slim as possible and I want them to contain only the
code they need for their main job. For TAChart, the main job is to plot
data, not to evaluate functions. Therefore, the formula parser should
stay outside the chart package in this way of thinking. In particular
since there are other libraries to parse math expressions, such as
"symbolic" which is distributed along with fpc as well.
Of course, runtime code should be separated from designtime code in the
first place.
Well, that was going to be my question.
Designtime should be separated from runtime to begin with.
Normally you should have 2 packages. One runtime, one designtime...
But if you make the expression chart a different component in a different unit,
(as I suggested) then it will not link in the fpexprparser unit at all unless
you actually use this component.
But I know too little about the TAChart architecture to comment further.
These values can only be handled in code. Of the three,
itFunctionHandler can be handled by using an event handler.
But itFunctionCallBack,itFunctionNode make no sense in the designer.
This means: If I select itFunctionHandler then the events
OnGetFunctionValue and OnGetVariableValue are fired? In this case
TPlotExpressionPanel would behave like TPlotFunctionPanel?
The event of the collection item will be triggered if you use
itFunctionHandler, yes. But obviously only during runtime.
BTW I was suprised to see a collection editor here although there is no
explicit code defining it. But then I realized that it's just the clever
usage of the word "published" and the selection of the specific
inherited class which achieves this. It is amazing how seamlessly the
design editors of Lazarus are integrated.
Hm. I no longer even think about such things. It's just normal.
Shows how spoiled I am, I guess ;)
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
https://lists.lazarus-ide.org/listinfo/lazarus
