[Lazarus] fpspreadsheet bug - and fix

Michael Van Canneyt michael at freepascal.org
Thu Oct 23 09:54:45 CEST 2014



On Thu, 23 Oct 2014, Werner Pamler wrote:

>>  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.

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

> 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).

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

>
> 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.

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.




More information about the Lazarus mailing list