Debugger tip. was RE: Output file ownership

[John Esak]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Fairlight
> Sent: Saturday, May 20, 2006 9:14 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: Output file ownership
>
>
> Y'all catch dis heeyah?  Tom been jivin' 'bout like:
> > Mark,
> >
> > Thanks. That worked well and I even understand it :)
>
> Glad I could help.  :)  (Did it work with a string literal as the second
> argument to writeline(), or did it require a rewrite to use a variable?)
>
> mark->

Literals are fine in almost every filePro syntax where an expression is
indicated. Very few exceptions. Another oddity (you might think) is that
real fields in the database can also be considered an expression. This for
me eliminates the need and/or use of the "f" function in the debugger. I
just use "e" for everything. (E)xpression works for virtually anything, real
fields, lookup fields, array elements, variables... and ... yes, even actual
expressions. :-) such as:

  14 + "14" / lookup(22) + array[i]

Using the (F)ield option limits you to fields, period... sort of a tiny,
crippled subset... and time/speed are money when trying to debug stuff, so
hence just using (E)xpression eliminates extra button pushing.

P.S. - One of the *very* few places where literals can not be used is in the
above example... that being the lookup subscript. It can not be a literal
(string) *or* an expression. I know this vastly irks many on this list...
but the overall flexibility filePro gains by allowing the use of real fields
without quoting and literals with... is quite amazing. There is no way to
compare this to C or even BASIC (more closely related to the roots of
filePro's processing language). It is just a different mind set that, once
embraced for the task at hand, works very well.