You can't do that

[Jeff Harrison]

--- John Esak <john at valar.com> wrote:
> 
> 
> > -----Original Message-----
> > From: filepro-list-bounces at lists.celestial.com
> >
> [mailto:filepro-list-bounces at lists.celestial.com]On
> Behalf Of Jeff
> > Harrison
[snip]

> > Here are some other "would be nices":
> >
> > Functions and arguments would be nice.  I would
> like
> > to pass arguments to a particular call (or chain)
> and
> > have it return a value.
> 
> Now hold on... am I missing something. This is
> pretty much *excactly* what I
> use CALL tables for in the first place. What do you
> mean???
>

Ok, to clarify here, I would like to do something like
the following:

returnvariable = call("mycode",arg1,arg2)

Does this make sense? This way I could pass arg1 and
arg2 into the call table without worrying having to
keep track of which variables should be used in which
tables and which ones should be defined as global, or
external, etc.  You could set aside new system
maintained fields like @p1, @p2, etc to refer to the
parameters within the "mycode" table.

Also, within "mycode", you could have a return
(returnvalue) statement that would return a value to
the calling table and populate the returnvariable
above.

[snip]
> > Rules for data integrity.  It would be nice to be
> able
> > to set up certain rules in define processing that
> > would prevent certain situations from being
> allowed.
> > For example one could set up a rule to ensure that
> > there would be no child data without a header
> record.
> > Another rule could be that a certain field must be
> > filled in and no duplicates allowed, etc.
> 
> I hear what you are saying... but it sounds like
> setting up some tight
> library CALLS might do this. I'm not trying to say
> filePro can do everything
> you're asking for in this regard, and this sounds
> like a neat idea, but then
> again, even if you had these built-ins, wouldn't you
> change them once in a
> while to do exactly what you want. So, therefore
> wouldn't good library
> functions developed over the years do the same thing
> for you and be closer
> to how you like things done anyway?
[snip]

No, I don't think so.  I'm talking about making
certain customizable rules that would be imbedded into
the structure of the filepro file.  If someone
attempts to break these rules - almost certainly it
would be because they made a programming mistake. 
Therefore an error would point out the mistake to the
programmer and not allow the corruption to take place.

Yes, I could change the rules, but if I do, and
corruption takes place, then shame on me!

Library routines would not work for this because there
would be nothing to enforce the use of these routines
on the programmer.  And who is to say that an error
would not get introduced into these routines anyway?

[snip]

> I, like you, have never even considered needing an
> "else" statement. If-Then
> covers it for me... but, I would like a completely
> new construct... for
> filePro that is... like maybe "while-do" or even
> "do-while" I'm not picky.
> 

Good point. Oh, a case statement would be nice too!

Jeff Harrison
jeffaharrison at yahoo.com

Author of JHExport and JHImport.  The easiest and
fastest ways to generate code for filePro exports and
imports.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com