Paradox Community

Items in pnews.paradox-dos

Subject:Progress plus PROBLEM
Date:Sat, 25 Aug 2018 06:42:37 +1000
From:Bernie van't Hof <>

Am progressing well with forms:
- figured out some last details from SET files and am incorporating them
- displaying master and detail forms (single and multi-row) with data.
- repeating area text (not data) still to do, but shouldn't be too hard.
- calculated fields parsed and displayed.
- slowly rationalising display formatting.

However, calculated fields have finally forced me to consider an issue I placed in the too-hard-for-now
basket a long 
time ago! Anyone willing to toss in some thoughts (please)?


pdox is loosely typed and uses the same operator (+) for string concatenation and arithmetic
addition, applying rules to 
work out which process to invoke depending on data types involved.

Php uses different operators for string concatenation ('.'), and arithmetic add ('+').

The parser does its best to identify data types and translate to the appropriate operator, but
this fails if the data 
type is not known until run-time.


1. Add one or more new operator(s) to PAL to force correct operation (easy), but this would
require modifying PAL source 
code and it wouldn't work in pdox any more, and the pdox forms calculated fields editor won't
allow them.

2. Ignore the problem at translate time, possibly producing an "issues" report, and manually
modify the produced php 
code to taste. But this must be repeated every time the source PAL code is translated.

2a. Currently form files are converted, and calculated fields are parsed and converted, on-the-fly
at run-time, so 2. 
won't work.

2b. (Thinking aloud) Parsing and translating calculated fields could be done at the time a form
file is parsed. This 
fits with the plan to store, cache and modify converted forms.

4. Add directives via pal comments to tell the translator what to do. This does require modifying
the src PAL code, but 
survives repeated translate runs, but doesn't address the forms calculated field problem.

5. Ideally this could all be handled by code inserted into the generated php (like variable
scope management is done 
currently), but that could make the generated php look very different to the original PAL, and
potentially a lot more 
complex, which would make it harder to work with and maybe more fragile.


There will be a "best" solution somewhere, but am trying to keep with the core concept of running
converted unmodified 
PAL code, a target that is so far being largely achieved.

Welcome to my (crazy) world.

- Bernie

Copyright © 2004