Hi,

No idea who is the current maintainer of fpspreadsheet, but to those involved:

I updated - after a long time - my version of fpspreadsheet.

There is a bug (apart from breaking backwards compatibility) which makes it difficult to use:

fpexprparser depends on unit fpsfunc.
fpsfunc depends on fpsexprparser.

This circular dependency creates a problem:

When I compile the fpspreadsheet package, it compiles.

When I compile my project that uses fpspreadsheet, the compiler complains it cannot compile fpexprparser, that it must recompile it because fpsfunc changed.

I then removed the dependency of fpsexprparser on unit fpsfunc by simply removing the unit from the uses clause.

After that everything compiles without errors: the package and the project, making me wonder why this circular dependency was introduced to begin with ?

Anyway:

May I please suggest that the fpexprparser unit is changed in this manner permanently ? I prefer to work with third-party sources as-is.

As a side note, I found that fpsexprparser is a fork from the exprparser unit in the FCL. After some studying, it seems to me that with little effort, the FCL version could have been changed to suit the needs of the fpspreadsheet project, making a fork superfluous: a simple descendent would have been sufficient...

Is there a reason this was not done ?
After all, improvements to existing components are always welcome...

Michael.

No idea who is the current maintainer of fpspreadsheet

I'm doing most of the development currently, no idea if I am the maintainer then...

Thanks for pointing me to this bug which I've seen for some time, but did not take seriously enough. But your solution is not working here, in fact I don't understand why it is working at all since the fpsfunc needs the TsBuiltInExpressionManager which is declared in fpsexprparser.

Now I removed the dependence on fpsfunc from fpexprparser, and after moving the "RegisterStdBuiltins" from fpexprparser to fpsfunc and the "ExprFormatSettings" from fpsfunc to fpsexprparser, the packages and demo projects compile. But now the built-ins - a central element of the parser - are no longer registered in the parser unit itself which does not seem right to me ( --> r3678).

I am aware of the fork of the exprparser, and initially I had been trying to extend it to fit into the fpspreadsheet infrastructure. But soon I realized some limitations of the exprparser: The parser uses hard-coded programming-style expressions which are not used in the spreadsheet environment. The hard-coded "and", for example" interferes with the "AND()" function of the standard spreadsheets. My main difficulty was how to put cell references into the existing code. This naturally leads to a dependence on fpspreadsheet. And even with the present version I am fighting with the rather strict data type checks of the parser. Finally I decided to fork the parser to get me a step forward. But if you have a better idea I'd be happy to use it.

Hm. Strange indeed. Maybe an issue with left-over files.

You can simply register them in another unit which is (presumably) always included when using fpspreadsheet ? I will have a look tonight.

Normally you simply need to register the existing cells. If that is a problem, the function to treat identifiers can be made overridable, so you can handle this in a more convenient way.

And even with the present version I am fighting with the rather strict data type checks of the parser. Finally I decided to fork the parser to get me a step forward. But if you have a better idea I'd be happy to use it.

I had this problem (hardcoded AND and other identifiers) in another project as well. This can be solved rather easily with a simple modification to fpspreadsheet: tell it not to recognize register certain classes of standard operators (AND/OR/DIV etc). They are then recognized as identifiers, which in effect transfers control to you.

That would enable you to solve your problem of the circular dependency rather easy. the builtins fpsfunc then needs to use the fpexprpars unit only, and fpexprpars can depend on fpsfunc.

I will have a look and contact you.

Michael.