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

Sat Oct 23 07:51:42 PDT 2010

>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.celestial.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