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

[John Esak]

Ken,

I'm really sorry about this... I asked him not to start it all up again...
But... Well... It must be impossible to just understand that  there is a
"preferred" or "accepted" or "correct" or even just "better" way to do a
thing... Even maybe just a "conventional" way.  I think none of this matters
to George, he just took such a beating on trying to defend that "WRITE (or
more simply put, assigning values) on the AUTO table thing" was a good idea
way back in 198? 6? 7? 8?  That he still hasn't recoverd... :-) and wants to
be "right" (no pun) so much that he just will never admit that it is not
only not a good idea, but an expressly bad idea.  It could be a matter of
"face".

Let's see, you work for Flowersoft, right George. Is that a flower company
of some sort or deals with flowers/florists? How about this... Would you put
black roses all over the tables at a happy wedding, or wear bright happy
colors to a funeral?  Does that make sense to go against such conventions?
And those analogies are only a "convention" they don't even actually *cause*
any problems. In the filePro thing, the data representation or storage can
actually be messed up by not following some conventions.  

Yeah, I know, they were bed analogies.  So that didn't work... Okay, how
about being third on a match?  If you were the third to light your cigarette
in a foxhole on the same match, the enmy had a chance to get a bead on the
flicker and you are the one shot in the head...  Okay, wait, that's a little
gruesome.  But, what everyone is trying to tell you, is that no matter how
much you argue it, there is NO good reason EVER for assigning a value on the
AUTO table in filePro, and there will definitely *eventually* be times when
it will *hurt* your data (the WRITE hurts indexes... Well, not your "data"
exactly, but a representation of your data and that's bad enough).  Yes, you
can argue that in some ways, this or that procedure does not seem to
disclose the problem, because you can't see it, but it still doesn't make
sense.  Why ever do anything the expressly WRONG way when there is an easy
and RIGHT way to do it? I would say I'd be glad that anyone building a
hurrican proof house, wouldn't take the WRONG way of doing things once in a
while just because it might not be seen and it was cheaper... Wouldn't you
want the house built according to known and accepted good practices no
matter what?

Does any of this make sense to you?

I think in the very end analysis people are telling you this not because it
is about STYLE of writing code... No one would ever suggest there is a
proper STYLE (although, I would strongly argue that STYLE *is* an important
part of writing good code...) but because it is expressly a BAD way to do
it. Assigning a value to a field every time it is retrieved off the media...
And sometimes keeping that assignment only in memory when the real value
stays unchanged on the media... Or worse, *forcing* the assignment of a
value on the AUTO table with a WRITE which would be doing it when the record
is NOT locked... Thus corrupting indexes and causing general mayhem....
Well, I just have to ask. Why are you pushing your point?

John

I'm not trying to be smart or piss you off, but Ken has used logical
statement after logical statement and you don't want to admit you are wrong,
maybe just simply asking you why you want to be right on this point is a
more important question to ask, and by telling us, we can move on to other
things.



> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> m] On Behalf Of Kenneth Brody
> Sent: Wednesday, October 20, 2010 11:19 PM
> To: flowersoft at compuserve.com
> Cc: filepro-list at lists.celestial.com
> Subject: Re: Modifying real fields in automatic (was Re: Some 
> Sort of ControlFrom The Browse Screen)
> 
> On 10/20/2010 5:16 PM, flowersoft at compuserve.com wrote:
> > I didn't put it in input processing because I didn't want 
> other users to be
> > affected by the code
> 
> And putting it in automatic won't affect other users?
> 
> > and still wanted the user toggling field 5 to be able
> > to actually modify other parts of the record if he/she 
> wanted to.  I was
> > doing that by allowing the user to hit "break" from the 
> browse and then put
> > them on screen 1.
> 
> You still haven't given any reason why you can't put it in 
> input, where it 
> belongs, rather than automatic.
> 
> > Since you can only detect @sk="brky" from automatic when 
> not at an input
> > statement,
> 
> Huh?
> 
> > that's where I put the 3 lines of code.  No one will ever be
> > affected by those 3 lines of code except that user.  In 
> input processing,
> > everyone would have been exposed to the code and I would 
> not have been able
> > to take the user out of the browse and unto screen 1 by 
> trapping the break
> > key.
> 
> I don't follow.  What, exactly, do you want to do if the user 
> presses Break 
> that you "can't do" if the assignment to field 5 is in input?
> 
> > Maybe I could have found ways to do all this from input but 
> I only spent 15
> > minutes or so coming up with the code.  At that time, I 
> didn't want to make
> > it my life's work, I just wanted to give him a quick 
> solution to the problem
> > he was facing without asking him to use a totally different 
> method or just
> > that it could not be done.
> >
> > Your argument is that it is wrong because it is just wrong 
> to assign values
> > to real fields from automatic processing in general.  
> That's like saying
> > that guns are bad because they kill people.
> 
> Actually, I think it's more like saying "don't point a loaded 
> gun at a 
> person, even if you don't plan on pulling the trigger".
> 
> >  My argument is that yes, maybe
> > guns are bad because they kill people but you prove 
> otherwise, in this
> > particular case the gun is not loaded and the safety is "on". :-)
> 
> I think you loaded the gun and the safety is off, and you're 
> hoping that no 
> one drops it.
> 
> [...]
> 
> -- 
> Kenneth Brody
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list