Modifying real fields in automatic (was Re: Some Sort of ControlFrom The Browse Screen)

[John Esak]

I know most on the list are probably never going to see this note, because
they've pressed DELETE like I do on many of the threads that lose interest
for me.  If you haven't, read the P.S.  If you want the whole gist of this
note without reading it all... :-)

It wasn't worth 15 minutes... Unfortunately... I know that you can not
update from the IUA browse without sacrificing lots of other things in the
process. I like using the "u" key for the (U)pdate function, period.  I have
spent hours and hours on it before this umpteenth time it has been asked. I
wasn't short changing Scott on an answer. I knew there was no really good
solution before he asked, and I still don't think there is a manageable way
of doing it.... Because even your way, requires there to be a specail table
involved. Good God, what do you think Ken and others have been saying... If
you are going to use a special processing table in the first plaec, why not
just write an absolutely perfect, full blown process that lets you use any
key to modify the browse, with complete control, and all the features and
functions of processing available to you?  The right way to do this job is
with a processing browse, period.  There, you've forced me to say it. yes,
the point I was making before, was that STYLE does count quite a bit, maybe
not as much as the dreaded PERL idiots Fairlight mentioned, but on the
whole, good style denotes care and thoruoughness of design. Starting off
with a bad idea, no matter how much you fixw it up and say it works so it is
okay... Is, in my opinion, a bad idea.  I just don't know how to say it any
other way, George.  We flat disagree.  It does not mean I think you are not
a great filePro programmer and certainly you prove it all the time... Even
now in coming up with this idea in 15 minutes. Like I say "kudos"... It's
just that I would never do it.

And thanks for the clarification that you entered the idea first. Sorry,
about that I thought he had suggested it earlier on. 

Oh, and as for only people using the -y myauto changing the value... What do
you think I meant?  Two people using normal processing?  :-)  I meant
everyone involved using your processing, do you want to state which person
will see the correct value or not in that case? That is the only sceneario
that matters in this discussion, no?

Believe me, if you choose not to answer this question, because it is
difficult, or because of any reason at all, I will not be unhappy. Again, we
have beat this thread (and appartently you) up all over one more time... And
I'm fine with it dying here.

John


P.S. - But, just to give everyone a laugh .. And let me have the last
word... Which I always like (assuming you let this be the end also, which
you certainly don't have to do... :-)

For the uninitiated... And I mean the really uninitiated... The ones who
have No idea why this is such an emotional filePro issue... Or at least one
that appears so "debate-able".  Here are some basics that simply can not be
denied.

#1  When you run a report against a filePro file, the AUTOMATIC table runs
on each record *before* the actual report process runs on each record.  Keep
this in mind.... It is critical.  (Yes, you can specifically cause filePro
to NOT run the AUTO table, or run a *different* processing table than the
standard AUTO in place of it, but by default, usually, normally, by *design*
that is... The AUTO table runs every time you run a report.  (And by the
way, every time you simply bring a record to the screen in IUA...which may
even be more important to this example.... But I'll use report as my demo.)

First, build a test filePro file. Let's call it "test".  Put on ly 1 field
in it and make it 5 in length and .0 edit type.  Build a default screen when
asked. Now, go add some records to the file.  Add about 5 or 6 records and
put a 1 in the first record, 2 in the second, 3 in the 3rd and so forth.  So
you might have 1,2,3,4,5 as the values in those records.

Now, build a "report" for this file. Let's make it a REPORT type format, and
don't put anything on the report other than *1 somewhere on the first line.
Do not put any processing at all. Leave the processing table blank. So, this
is a report that is supposed to do absolutely nothing but show the values of
this file.

Now, before you run this report, go and add one line to your processing
table. Just add this:


    then: 1 = 1 + "1"

Okay, all this does is add "1" to the value of field one.  Now run your
REPORT called "report".  


   .../rreport test -f report -a -u

:-)


Of course anyone with any filePro experience will start laughing... Because
they see immediately. That *every* time you simply run this report, it is
going to corrupt the value of field 1.  I say corrupt and not change,
because the AUTO table is *never* supposed to change the value of any real
field.

Forget running this report. Go into Inquire, Update and Add on this file.
Just look at screen.0 and start pressing the down arrow through the
records... Are you seeing the correct value of field 1?  Check the
difference between the full screen version of the value shown and the value
shown on the Browse of records.  You will see they are completely different.


This is why, my argument that *ever* changing the value on a real field in
the AUTO table is a bad idea.  If just down arrowing through the records to
see each record *changes* each record as you do it... Well, can you not see
this is something you would *never* *ever* want to do.  Did I use enough *'s
and ever's and never's??  :-)  If I didn't, add a few of your own.

So, George, you can keep arguing, I'm kind of sure you will somehow. :-)
But, seriously, do you think you will ever convince me? I kind of doubt it.


The sad, and kind of unbelievable thing is... That if you would just
re-write your great idea (and h0nestly, I admit it is really a good idea...
And I did NOT think of it, so shame on me...) ...  If you would ONLY just
re-write it as Ken (and I and everyone suggests) to be accomplished through
the INPUT table where it should be done... Well, George, I would have
NOTHING to argue about.  I don't think any of us on the list can understand
your reason for as I say... Pushing your point.  It is what is known in
debating parlance as an indefensible point.  There aren't many of those...
But you certainly have found this one. :-)

Have a great day, I hope you don't take any of my jibes as serious. Take
them in the context of friendly debating... Because, as you know, I highly
respect your filePro talents. I don't say that often, or to many, so take it
as the compliment that it is, and take this whole argument with you as what
it is... Friendly debate.

John


> -----Original Message-----
> From: flowersoft at compuserve.com [mailto:flowersoft at compuserve.com] 
> Sent: Friday, October 22, 2010 4:53 PM
> To: john at valar.com; filepro-list at lists.celestial.com
> Subject: RE: Modifying real fields in automatic (was Re: Some 
> Sort of ControlFrom The Browse Screen)
> 
> >By the way, in your scenario, two people accessing the same record at
> different desks, which one do you think will be >dealing with 
> the "correct"
> data for field 5?  The first one, the second one?  And if one 
> of them sort
> of simultaneously changes the value of field >5 while 
> actually in another
> process... Say in update mode... Who then is seeing the most 
> correct version
> of field 5?
> 
> They will both be seeing the correct value for field 5, as it does not
> change from the normal automatic processing.  It only changes 
> if you are
> running -y "myauto"
> 
> >By the way, kudos for coming up with something in 15 minutes 
> that does the
> >job... Well, to your measure anyway.  That's pretty good... 
> I really did
> >think it was impossible. But, to be honest, if you look over 
> the thread, I
> >think it was Scott himself who thought of a workaround 
> before you.  At
> least
> >in my sequential reading, I saw his solution first.
> 
> Well maybe you had the messages sorted in reverse order.
> My post was dated 10-16-2010 11:04 PM and his response...
> " Thanks for the methodology.  I'll give it a try.  Here's 
> what I thought
> might work:"
> Was posted on 10-17-2010 12:02 AM
> 
> >But, you are right, my bad... I absolutely did say I thought 
> it was not
> >possible at all... And it *can* be done in the way you 
> suggest.  I only
> >admit that because, if you were ever to rewrite it as Ken suggests,
> >correctly in INPUT processing, than you truly would have 
> found a solution
> >where I did not think of one.
> 
> As I said, there are probably 50 better ways to do it.  I 
> just didn't see
> one posted before I posted mine.
> 
> >(In my defnese) unfortunately, I gave my several responses 
> in less than 10
> >seconds each... Not 15 minutes. :-)
> 
> Perhaps you should have taken the 15 minutes. ;-)
>