FW: Browse lookup - odd behavior

[John Esak]

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

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.

JE