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

[John Esak]

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". :-)
>