FW: Browse lookup - odd behavior

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of Jay R. Ashworth
> Sent: Friday, July 16, 2004 9:50 AM
> To: Fplist (E-mail)
> Subject: Re: FW: Browse lookup - odd behavior
> 
> On Fri, Jul 16, 2004 at 02:22:52AM -0400, John Esak wrote:
> > > > > > And what would you cache instead?
> > > > >
> > > > > Whatever "lookup" information was use to generate the 
> lookup in 
> > > > > the fisrt place, modulo whatever row-count offset has been 
> > > > > generates by user navigation.  That wasn't obvious?
> > > >
> > > > What about records that have been added/deleted since the
> > > lookup was last
> > > > run?  Starting at the 37th record is no longer a valid 
> place to start.
> > > >
> > > > And what about keeping track of dropped records?
> > > >
> > > > Or are you suggesting actually re-running the lookup in 
> its entirety?
> > >
> > > Doing anything else seems semantically inadequate, as 
> this problem 
> > > demonstrates.
> > 
> > No, the problem demonstrates once again that there is a 
> simple and "proper"
> > method for writing this code so that the problem would 
> never occur in 
> > the first place. Trying to have the browse window which 
> already has "set"
> > criteria determine what to do after it gathers "valid" 
> records is not 
> > realistic. That is one excellent reason for the existence 
> of the prc stub.
> > In fact, one of its original intended functions. Having it written 
> > into the lookup line is not a good idea, not when considering the 
> > browse window may be displaying records in reverse order 
> (descending) 
> > on an index which itself may be in descending order, the 
> position of 
> > the highlight, the size of window, the size of file (in records), 
> > etc., etc. Not at least to do this all efficiently and without 
> > re-reading-executing the entire lookup as you are suggesting. The 
> > browse will match the original criteria, and by simply adding a  
> > "DROP" for any record not matching the specified key, the problem 
> > disappears. I suggested this solution to Richard in the FP 
> Room before 
> > he talked with FP Tech. Without knowing or thinking too 
> long about why 
> > the problem was happening, it was not difficult to suggest 
> a good method for coding that would eliminate it.
> > 
> > In most cases, one will not be deleting _and_ re-using the 
> records in 
> > any particular browse lookup. If, the browse being written 
> does look 
> > into a file that may be being updated simultaneously by 
> other users, 
> > then adding the DROP is not only no big deal, but a 
> required addition 
> > to the browse construction as filePro is now implementing it.
> 
> Well, that's all fine, John... but is that really the only 
> reason he's deleting the lookup records?  If he really wants 
> them *gone*, then pretty clearly, just doing a DROP isn't 
> going to help him much.
> 
> > As always, I take issue with your always immediate evaluation that 
> > whatever being discussed is a "bad design" decision, 
> especially when 
> > your instant-fix suggestions are always far short of the 
> mark in their 
> > scope and actual usability. Send up some code for a browse 
> that works 
> > better than filePro's does next time, rather than the usual flip 
> > response of "I could do it better, and isn't it 
> obvious?"... when you 
> > really can't... and more people might take your suggestions 
> seriously.
> 
> We were no longer discussing his specific case, except as a 
> pedagogical example.  I stand by my assertion.  If a browse 
> lookup is done on index keys, and it internally caches record 
> numbers heedless of the fact that other things may externally 
> change them and cause them to no longer be part of the 
> semantically defined lookup, then the lookup code is Broken 
> As Designed.
> 
> Hope you didn't injure your knee on the desk, there, John.  :-)
> 
> Cheers,
> -- jra
> -- 
Just to add my 2 cents into this discussion.

Jay, remember, I have set pkeep for this browse.  I will assume that if I
didn't, and let the browse close, delete the record and then re-execute the
browse, The browse would function as you indicate it should. 

With pkeep set, the browse stays open and allows for the fast redisplay of the
data.  Keep in mind what the speed of the computers was when the browse lookup
was added.  With the slow machines at the time, the display of the information
could take a significant time.  With pkeep, the redisplay of the data was quick.
With the speed of today's computers, it is possible that other design choices
may have been made.  

As John said, adding a drop to the browse will solve the problem.  This does not
entail jumping through programming hoops and acts as insurance against an errant
detail line being displayed.

Richard Kreiss
GCC Consulting