dummy fields

[flowersoft at compuserve.com]

I've always been curious as to why the parser can't handle
If: not not
Where not is a label or
If: not gt 6
Where not is a long variable
when it can handle some of the other much more complicated things mentioned.
Maybe because the parser was written before long variables but then, I don't
think it was written before labels, or was it?

-----Original Message-----
From: filepro-list-bounces+flowersoft=compuserve.com at lists.celestial.com
[mailto:filepro-list-bounces+flowersoft=compuserve.com at lists.celestial.com]
On Behalf Of Kenneth Brody
Sent: Wednesday, October 20, 2010 1:18 PM
To: Fairlight
Cc: filePro Mailing List
Subject: Re: dummy fields

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
_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes
http://mailman.celestial.com/mailman/listinfo/filepro-list