https://bugs.freepascal.org/view.php?id=32653

wp wrote: >>Sorry I will not fix this one because it opens another Pandora to add features well-established in TAChart.

Pls apply the patch. it makes several plots on one panel. What Pandora?? I don't know Pandora, I use Laz and LCL.

-> https://en.wikipedia.org/wiki/Pandora%27s_box :-)

-Michael

@Alexey

>What Pandora?? I don't know Pandora, I use Laz and LCL.

Today the phrase "to open Pandora's box" means to perform an action that may seem small or innocent, but that turns out to have severely detrimental and far-reaching negative consequences.(https://en. wikipedia.org/wiki/Pandora%27s_box)
What @wp meant is you can already use TAChart, developing similar features in PlotFunction in parallel would be an overkill.

On Tue, Nov 7, 2017 at 11:55 AM, Alexey via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171107/1e7a8fc2/attachment.html>

Am 07.11.2017 10:56 schrieb "Alexey via Lazarus" <

:

https://bugs.freepascal.org/view.php?id=32653

wp wrote: >>Sorry I will not fix this one because it opens another Pandora to add features well-established in TAChart.

Pls apply the patch. it makes several plots on one panel. What Pandora?? I don't know Pandora, I use Laz and LCL.

The Box of Pandora is from Greek mythology (look up its meaning on Google). It's sometimes used in a context where "opening a can of worms" is also appropriate - namely a situation that one doesn't want to do because one doesn't want to deal with the consequences.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171107/72e03a76/attachment.html>

First: in your patch it is not clear which curve belongs to which function. Therefore, the next thing which will be requested it a legend. I am 100% sure!

Second: your patch is valid only for the event panel, not for the expression panel. Next request will be to enter several expressions there; this requires a proper design-time editor.

And the more features are added the more requests will come up...

In essence, all these patches will add features to the plot funtion panel which are well-established in TAChart. It is a waste of time to bring two charting packages to a comparable level and to maintain them. And in fact, there's even a discussion going on among the developers to move plotfunction out of Lazarus into ccr.

Did you ever look at TAChart? It may be a bit intimidating at first sight, but I wrote a bunch of tutorials in the wiki. I am absolutely sure that you will master this. The function series which does what lazplotfunction is doing (plus a lot more) is explained in http://wiki.lazarus.freepascal.org/TAChart_Tutorial:_Function_Series.

Are you going to make sure TAChart can do the plot during design-time ?

Michael.

Michael Van Canneyt wrote

Are you going to make sure TAChart can do the plot during design-time ?

I am working at it, there are issues with registration of the new TExpressionSeries from a separate package (it's not in trunk, yet).

But anyway: why is the designtime argument so important to you? ExpressionPanel cannot plot a function as simple as "sin(x)" at designtime because bcMath is not added to the Builtins of the parser. And if it were, other similarly simple functions such as "tan(x)" would not work because they are not registered. So, the designtime argument has only very limited weight. But of course, there is always the possibility that I am missing some features of the fpexprparser.

I am _very_ surprised by this question.

Because Lazarus is RAD, obviously ? No-code development ?

In your eyes, yes. In my eyes, this is _the_ argument:

TDataset has the possibility to show the data at design time. In it's day, this was revolutionary, and still today - 20 years after the introduction there are very little environments that can repeat this. (in fact, I know of none)

The same applies for plotpanel.

If TAChart cannot show a series in designtime, then that is a huge shortcoming in my eyes.
(Never having used TAChart, I don't know if it can or not, this is a hypothetical statement)

But of course, there is always the possibility that I am missing some features of the fpexprparser.

No, you are not missing it.

I see that I missed to commit a patch to plotpanel, because here sin(x) works. I have too many unfinished patches in my source tree :/

Should I still commit it, or it is not necessary any more ?

Michael.

Michael Van Canneyt wrote

I see that I missed to commit a patch to plotpanel, because here sin(x) works. I have too many unfinished patches in my source tree :/ Should I still commit it, or it is not necessary any more ?

Please commit it. I think we should fix the shortcomings of plotpanel. There were already a few bugs which I fixed - look at the svn commit notes. I'm just against adding too many new features which just will be appetizers for even more new features.

In the meantime I put the TExpressionSeries into the standard TAChart package where everything works fine (in order to remove the dependence on fpexprparser, maybe I'll move it to a separate package later once I know how to get the registration for the series editor done). Here are short instruction how to use it

* Add a TChart on the form
* Double-click the chart
* In the "Edit series" dialog select "+ Add" and "Math expression series" at the very bottom.
* In the Object Tree, select the newly added serie, Chart1ExpressionSeries1
* Enter the function term, e.g. 'sin(x)*exp(-0.1x)'
* Define the x range for which the function will be plotted: Select "Range", enter the minimum and maximum x values, e.g. XMin = 0, XMax = 50, set UseXMin and UseMax to true in order to apply this axis range.
* Set AutoExtentY to true in order to auto-scale the y axis.
* Voila - see the attached screenshot (which is taken at designtime, of course).

Michael, the expression panel allows to add
do understand this for variables, and, in fact, this is great to parameterize the function or to use natural constants. But the IdentifierType can also be itFunctionCallBack, itFunctionHandler, itFunctionNode. Can you explain how these should be handled in practice?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171107/0bcfddfd/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: gehbmdghpmljpdpk.png
Type: image/png
Size: 6612 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171107/0bcfddfd/attachment.png>

OK.

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 ?

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.

For simplicity, the plot panel uses the default collection editor, so the other values are exposed as well in the designer. A specialized collection editor would simply hide these possibilities. (and would also disallow editing the X variable)

Michael.

 >missing some features of the fpexprparser.

I couldn't find fpexprparser folders in FPC 3.0.2 and Laz- where is it?

Alexey wrote

I couldn't find fpexprparser folders in FPC 3.0.2 and Laz- where is it?

(fpc)\source\packages\fcl-base\src\fpexprpars.pp

Can you add to FPC some example which uses this engine?

(fpc)\source\packages\fcl-base\src\fpexprpars.pp

Michael Van Canneyt wrote

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.

This means: If I select itFunctionHandler then the events OnGetFunctionValue and OnGetVariableValue are fired? In this case TPlotExpressionPanel would behave like TPlotFunctionPanel?

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.

Alexey wrote

Can you add to FPC some example which uses this engine? > (fpc)\source\packages\fcl-base\src\fpexprpars.pp

http://wiki.lazarus.freepascal.org/How_To_Use_TFPExpressionParser

And, of course, the TPlotExpressionPanel (the other component in the package "lazplotfunction") is a nice application of it (see TExpressionControlPlotter.Create, .SetExpression, and .CalcFunction).

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.

The event of the collection item will be triggered if you use itFunctionHandler, yes. But obviously only during runtime.

Hm. I no longer even think about such things. It's just normal.

Shows how spoiled I am, I guess ;)

Michael.