dummy fields
Kenneth Brody
kenbrody at spamcop.net
Wed Oct 20 10:17:52 PDT 2010
On 10/20/2010 5:27 AM, Fairlight wrote:
[...]
>> Dummy fields that are declared in the automatic processing table will be
>> shared among all processing tables(*). Those that are not, are not shared
>> at all.
>>
>> (*) The exception, of course, being those called via "CALL NOAUTO".
>
> Questions...
>
> 1) I'm not familiar with CALL NOAUTO; please explain what this does? The
> 4.8 docs that Bob Stockler gave me in man page format don't contain any
> reference to "noauto" (case insensitive grep yielded nothing). I'm
> assuming it's a 5.0 or 5.6-ism.
Why are you using a manual for such an old version of filePro?
In any case, CALL NOAUTO calls another processing, but does not "share" any
of the dummy fields declare in the automatic table.
> 2) Possibly more importantly... Let's say you're in file "file1" and have
> a dummy variable "tn" defined in automatic processing. Now, let's say that
> somewhere in the input processing table, there's a CALL "file2/specialtable".
> Is "tn" shared between file1's automatic and file2's specialtable? Or is
> the scope limited to only processing tables within file1?
The location of the prc that you're calling is irrelevant.
> 3) Are dummy variables matching reserved operators valid? Examples: co,
> eq, gt, et, le, lt. My recollection is that thoy -are- valid, but I wanted
> to doublecheck.
Yes, they are valid. This is perfectly valid, assuming the dummy fields are
defined somewhere.
If: co ge lt or ge lt co
> And if they are valid, how does fP's parser go about
> detecting whether "gt" is greater than, or a field for a grand total, for
> instance?
Context. For example, in my "if" statement above, there is only one
possible interpretation.
Field "co"
| Greater than or equal
| | Field "lt"
| | | Boolean "or"
| | | | Field "ge"
| | | | | Less than
| | | | | | Field "co"
| | | | | | |
If: co ge lt or ge lt co
Same thing with events:
@wgt -- Grand-total event
@wlfgt -- Leaving field "gt" event
> What's the methodology, placement within a statement that is
> either within an argument list (as with MID(), for example), or if one of
> those reserved combinations essentially -doesn't- fall between two
> "objects", then it's considered a dummy field, but if it's not part of an
> argument list and it does fall between two "objects/clauses", then it's
> considered an operator? I'm imagining that detecting the non-argument-list
> semantics is essentially done by breaking up the statement into its
> component clauses and then seeing if something falls in position 1, 2, or
> 3...if it's in position 2, it's an operator, if not, it's a dummy field.
> Is this even remotely a sane way to tell which something is...assuming that
> dummies that match reserved operators are even valid?
Can you give a specific example where the usage would be ambiguous?
--
Kenneth Brody
More information about the Filepro-list
mailing list