You can't do that

[John Esak]

> >Lets throw away edits and do all the equivalent work in
> processing, because
> >you're the programmer and it's up to you to just write it how
> you want it
> >right?
> >Can anyone possibly claim this would not be a huge downgrade if not a
> >complete disaster?
> >
> >Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
> >+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> >filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!
> >
>
> I said nothing about removing the edits..that's putting words
> into my mouth
> and is a really stupid statement,  maybe it would have been
> better stated to
> say that I don't think it would provide anything that isn't able
> to be done
> already when written correctly and why add more unnecessary
> features.. just
> my personal opinion..
>
> Scott....

Don't waste your breath Scott. It was precisely clear what you meant. The
above comment comes from the same person who just twice in the past three
messages claimed completely wrong things about filePro... then admitted not
even having tried the things he blamed filePro for doing incorrectly. In
these messages he also invented a nasty new saying about how badly
inconsistent filePro is... again being completely wrong. He was "stupid" in
both his nasty approach and his as usual lack of real evidence. Then, when
he was politely told by the author of filePro that he was indeed wrong (as
usual), this ass cleverly(?) excises his nasty remark about there being YAFI
and says "Thanks!" to the person he just so boorishly insulted. There is not
a lot of brain power or social awareness going on here. Trying to engage in
a meaningful discussion is impossible with him. Direct your responses to
Jeff and you'll be better off on the whole. May I also suggest implementing
mail rules that block messages from certain individuals on this list. You
will be much happier reading messages which don't start off on the footing
of bashing filePro. However, unfortunately, this doesn't prevent you from
reading the odd bunch of crap when it resides inside threads like this...
which start off okay, and then get polluted by those who can't debate or
discuss any issue without bringing along their childishness and rancor.

And, by the way, to try and drag the content of this topic back to the high
ground, Jeff's suggestion for "rules" that filePro supplies, does, as you
suggest, seem to be just asking for programming that really would be done
better by the programmer. I agree.  Why add another level of complication to
the now wide-open structure. My suggestion to Jeff, is put the wish into the
wish list and see if it gets moved up the priority list. It might, who
knows.

Also, if rules to aid in programming would be helpful in his opinion, then
he might expand into running Visual FoxPro, which is a full RDBMS system
that is replete with exactly such rules as he is suggesting. I would only do
so for the rare instance where that program could do a job better than
filePro... and there certainly ARE such instances. On the whole, though, I
would advise against trying to impose this type of rule system on filePro.
It is one of the things I DON'T particularly like having to deal with in
FoxPro. I do not, however, discount their validity for THAT type of
programming environment, they are very helpful to the programmer who is used
to that kind of paradigm.

And, if I might agree with Nancy's estimation of some of this... Jeff's
argument that a 2nd programmer can mess things up quite nicely... She is
right, but even the 1st programmer can mess things up badly if he/she does
not approach modification of an existing code set with great care. I don't
believe pre-imposed (canned) rules will help. Writing your own rules in the
first time along WILL help. If you don't want a child record of a file being
removed because it impacts on many other things... be certain to write that
rule (i.e., programming) into your original code. Someone adding/modifying
the code would simply have to be aware of what is required. Unless, we start
dictating that filePro start carrying databases and the equivalent of a
database container, there would be no real place to put such "rules" anyway.
Essentially, if you want to construct a rule that involves two tables for
example (i.e., filePro files), you would need to place these rules in an
"overviewing" structure or container that is aware of BOTH those
tables/files. filePro is just not the engine to do things this way... and I
would not agree with trying to make a silk purse out of this sow's ear. You
may think this an insult to filePro, but it certainly is not. It's just
recognizing that enhancements and wish list items should be aimed at things
that CAN actually be done. The other kind of suggestion is not
counter-productive... it is just non-productive because it can not lead
anywhere. It is why I suggested it would be nice for a while-do loop in
filePro. I *know* that is impossible as things stand now... maybe in version
8.0?  And if that happens, why not full GUI and the rules Jeff suggested?
Because it would be an entirely different product and engine... I'm not
saying I wouldn't like all that... I am repeating that there are hundreds of
other things I would like added into the "excising" real program as it sits
now before that pie-in-the-sky filePro happens.

John