dummy fields

John Esak john at valar.com
Wed Oct 20 04:18:31 PDT 2010


Mark,

Incidentally, why are you relying on such a silly set of docs for filePro.
Just log onto one of your client's machines and check out F10 in rcabe and
dmakemenu, it's all there. I'm sure your active clients would/should be on
5.6.  Although you worked a lot with Nancy right?  I think she has said that
she never moved to the 5.6 level.  So maybe all you'll see if 5.0, but that
covers most of it.

John


> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> m] On Behalf Of Fairlight
> Sent: Wednesday, October 20, 2010 5:28 AM
> To: filePro Mailing List
> Subject: Re: dummy fields
> 
> Only Kenneth Brody would say something like:
> > On 10/19/2010 10:09 AM, Fairlight wrote:
> > > Are dummy fields shared between processing tables that 
> are CALL/CHAINed?  I
> > > suspect yes to CHAIN but no to CALL.  I need to know what 
> the real deal is.
> > >
> > > Also, what about during calls to tables in other files?
> > 
> > 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.
> 
> 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?
> 
> 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.  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?  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?
> 
> Thanks in advance...
> 
> mark->
> -- 
> Fairlight->   ||| "Where's the real life in your     | 
> Fairlight Consulting
>   __/\__      ||| illusion? On the dark side your    | 
> http://www.fairlite.com
>  <__<>__>     ||| power's in confusion..." --Le Bon  | 
> fairlite at fairlite.com
>     \/        |||                                    | (502) 509-3840
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list



More information about the Filepro-list mailing list