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.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
