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

[John Esak]

Okay, okay, I'll give up... But I hope you realize that you just set up a
very controlled scenario to help prove your point. Sure, the AUTO doesn't
run on the browse, but nothing forces the user to continually go directly
back to the browse. He might also and often times will just press the down
or up arrow to see the whole record. The AUTO table runs. :-)

Just call me Anatole...   :-)

Seriously, I do admit that you have supported your point as best as humanly
possible.

Nothing would cause me to write this in AUTO instead of INPUT where it
belongs, so we are finally at part of the story where the little scrolly
letters say "The End" in the center of the screen. And as Jerry Garcia would
say... What a long strange trip it's been. 

> -----Original Message-----
> From: flowersoft at compuserve.com [mailto:flowersoft at compuserve.com] 
> Sent: Saturday, October 23, 2010 10:52 AM
> 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)
> 
> >No, more than one person might not be checking off returned 
> checks, but I
> think there was some other words about just >being able to 
> use the browse in
> this manner period, irregardless of the exact reason. I can 
> see lots of
> instances where >multiple people might want to be "marking" 
> things Y or
> N....
> 
> Even so John, think about it.  Let's say you and I are 
> marking off records Y
> or N, in two separate rooms, offices or countries, it doesn't 
> matter.  We
> are both using the same program with the "bad" code I posted 
> and we both
> have the same list of records that need to be changed.  
> Remember, all we are
> seeing is the browse screen.  I go to a record and press "U" 
> to mark it with
> a "Y".  Immediately, the browse screen shows the change, so 
> even if you
> browse to the same record 2 seconds or 2 hours after I marked 
> it "Y", you
> will see the "Y".  Only if you wanted it to mark it as a "N" 
> you would press
> "U" to change it.
> Automatic processing does not run when you are on a browse 
> screen looking at
> records.  Not even if you arrow through the records.  You can 
> press "B" to
> go to the bottom of the list, "T" to go back to the top, page 
> down, page up,
> press "C" to run continuously through the list.  No matter 
> what you do,
> automatic processing does not run unless you press "U" to 
> update the record
> or hit <Enter> to select the record.
> So even if browse and place your highlight on the same record I just
> changed, you will not be changing the record either in memory 
> or disk.  Only
> pressing "U" makes the tree fall in the forest while someone 
> is there to see
> it.
> So, is it bad coding practice?  Definitely.  Does the "bad" 
> code work in
> this case without breaking anything.  Absolutely.
> So my point again is that, you should never eliminate any 
> solution to a
> problem because it may not strictly adhere to standard 
> practices or common
> beliefs. Consider every option and then pick the one you 
> think it is best or
> most practical.
> Not to say that this is what I did in this case, I did not 
> consider every
> possible solution in the 15 minutes I spent thinking about 
> it.  However, I
> did not eliminate the possibility assigning the values from automatic
> processing just because theory says that you should not 
> assign values from
> automatic processing.  I did consider however, if my solution 
> would create
> any other problems and at that time, I did not see any so I posted it.
> 
> 
> I was stubborn as a chess player, and so I tried to defend 
> even very bad
> positions, and in many cases succeeded. 
> Anatoly Karpov
> 
> 
> -----Original Message-----
> From: 
> filepro-list-bounces+flowersoft=compuserve.com at lists.celestial.com
> [mailto:filepro-list-bounces+flowersoft=compuserve.com at lists.c
elestial.com]
> On Behalf Of John Esak
> Sent: Saturday, October 23, 2010 12:24 AM
> To: filepro-list at lists.celestial.com
> Subject: RE: Modifying real fields in automatic (was Re: Some Sort of
> ControlFrom The Browse Screen)
> 
> Ok, I see you had the right idea and stated it... But then by 
> going on and
> providing the solution he wanted you bypassed that good 
> advice I think.
> 
> A lot of times, don't you think warning a client that 
> something he wants to
> do isn't the best way to do it, and that is as important as 
> doing it for him
> the way he asked for it just because you can?  You were right 
> in all you
> said below, and then you obviate it by providing the not so 
> good method
> anyway. :-)  Yes, I did sort of miss this clear stuff you 
> said. Often, I
> skim notes and stop at the code... Hae to admit that is a 
> failing of mine.
> Well, thanks for the clarification. It seems we all finally 
> are on the same
> page.
> 
> By the way, I dfidn't even see the reason for the 
> application... Well, I
> think I saw it and forgot it. No, more than one person might 
> not be checking
> off returned checks, but I think there was some other words 
> about just being
> able to use the browse in this manner period, irregardless of 
> the exact
> reason. I can see lots of instances where multiple people 
> might want to be
> "marking" things Y or N.... 
> 
> This is a kind of stupid thing that I adopted awhile back.  
> Always, even if
> you are told otherwise, write apps as if mutliple users will 
> be accssing
> them simultaneously. In the end, it will just work out to be 
> smarter.  Can
> you imagine how different the world would be had Mr. Gates 
> and the crew
> thought of the original DOS stuff as being used my many at 
> once.  Think of
> all the legacy stuff we wouldn't have had to work around!  I remember
> thinking when Windows For Workgroups came out... Hey, that's 
> a good idea,
> that's almost like Xenix (and Unix!) :-)  Too bad it took 
> them until about
> Server 2003 to even really come close.... And there are those 
> like Bill C.
> who would say they still haven't even approached the bar yet. 
> :-)  So, I
> just always write for multi-user scenario... And even more... You may
> remember when several years ago... In a discussion with Bob 
> Stockler that I
> declared that every single app I ever wrote for filePro again 
> would work on
> any platform that filePro supports, and not require any 
> outside apps to
> function.  Within about a 95% margin, I think I've adhered to that
> standandard.  And just real quick to kind of prove out how 
> good it is to
> work that way....
> 
> When I worked with Tim at 21st Century Appraisals the past 
> two years agao...
> I worked on an enormous, complicated program that did a huge 
> conversion of
> one app to another...well one app to an upgraded version with 
> lots of new
> ahilities.  After it had done it's job and the new app was 
> working quite
> well in several locations... They came in and said... Oh we 
> have to move
> this all to a Windows system. I sid, okay, when?  ... :-)  
> ...  Guess what
> they said...   Two weeks from now!  :-)  I gage my usual "That's
> impossible!" answer and starting wearing my "That's 
> impossible" T-shirt into
> work efvery day... But it actually did happen... Because I 
> had taken the
> original time to to the upgrade stuff as if it were going to 
> work on both
> Unix and Windows.  Had I not done this, getting that app ready for the
> Windows site would have been flat impossible. I kept thinking 
> as I was doing
> the conversions involved... Boy, I'm glad I wrote that this 
> way... And God,
> I'm glad that has that in it... :-)  
> 
> Don't get me wrong, there aren't a lot of things that need to 
> be done to
> accomplish this portability, mostly it's in pathing and 
> "slashes" versus
> "backslashes" and not using USEr aNd such. It all is kind of drudge
> programming to add each time you do anything... But like I 
> said.. It saved
> my ass in this case... And many other times, too.
> 
> John
>  
> 
> > -----Original Message-----
> > From: flowersoft at compuserve.com [mailto:flowersoft at compuserve.com] 
> > Sent: Saturday, October 23, 2010 12:02 AM
> > 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)
> > 
> > Not that I don't want you to have the last word John, but...
> > 
> > >If you are going to use a special processing table in the 
> > first place, 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.
> > 
> > You seem to read and/or quote my posts selectively.  Did you 
> > miss the one
> > where I said to Ken:
> > 
> > "Understand that I'm not advocating that it is OK to update 
> > real fields in
> > automatic processing, just like I never advocated using 
> > "write" in automatic
> > processing, although I did find it necessary to use it in one 
> > case to be
> > able to accomplish what was needed.
> > 
> > "If I was tackling this problem I would have used the method 
> > you originally
> > recommended, which was to do a browse lookup from the main 
> > file and handle
> > it with processing.  Much cleaner, but that is not the 
> solution he was
> > asking for."
> > 
> > "He wanted a solution that would work from the regular browse 
> > screen and
> > that is what I tried to give him."  
> > 
> > >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 scenario
> > >that matters in this discussion, no?
> > 
> > You got me there. I must admit that during those 15 minutes 
> I did not
> > anticipate that two or more individuals might be checking off 
> > the items that
> > have cleared from the same checking account at the same time. 
> > However, if that were to be the case, my code would still 
> > work because the
> > tree doesn't really fall unless the user presses "U". :-)
> > 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list