A bug in pkeep...

[John Esak]

JP Radley commented on a line in the "pig" code which looked odd to him. I
wasn't going to mention it here and only replied directly to him, but just
today two other people questioned me about it. The line is just before the
browse and looks like this.

       . If: '5.x version
       Then: LkupKey="1"      'this must be a "1" for numeric pkeep to work
 11  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       . If: '4.8 version
       Then: l="1"            'this must be a "1" for numeric pkeep to work


       . If: '5.0 version
       Then: 'lookup det=(BrowseFile) k=(LkupKey) i=A -ng
b=(b_cfg&b_hdr&b_data)
 17  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       . If: '4.8 version
       Then: lookup det=(BrowseFile) k=l i=A -ng b=(b_cfg&b_hdr&b_data)

The reeason for this code is twofold. First, there is a shortcoming in the
4.8 version that did not allow both the alias=(filename) and the k=(key) to
be declared variables. One or the other I believe. This has since been fixed
in later versions of 5.0.

Second, I wanted to point out that there was (and I think still is even in
5.0.14) a bug that will prevent "pkeep" from working properly if the k=
value is set to null (""). The highlight will always return to the top line
of the browse and not the line it used to be on. By making this "1" as in
k=("1") the "pkeep" works properly. (I have a bug/task number assigned to
this from when I reported... at least I think I do, haven't checked in a
while.) The bug by the way only happens with "numeric" index keys as I
stated in my comment. Just wanted the rest of my code to work properly
should anyone change it to use a numeric account code or catalog item# or
whatever.

Meanwhile, none of this explains why I used a "1" with my test data which is
using a last name field... clearly not numeric. It is simple really, the
test data I used had many blank last name fields... just records with
company names and no contact.  I did not want the first browse to be seen to
look so empty and "wrong", so I purposely made the lookup bring you to the
first record that had a populated last name. Had I picked an "a" as the
lookup key, I would have accomplished the same thing, but I wanted to also
show the fix for a numeric lookup, and my inent was to kill two birds with
one stone. I really didn't think anyone would notice or care, because how
often do you start a browse at the _very_ beginning of a file anyway?
Often, you are starting it off somewhere in the middle of the index, and
that is specifically what I wanted to accomplish... and being that I had
previously been using a numeric-based lookup, I decided to show the pkeep
bug _and_ get me to the right place in the browse.

Only three people did notice and questioned it, and only JP actually tried
it with a null ("") key to see if it would still work... Well, it works with
alpha but not numeric. End of story. Next time I'll be more wordy about it
all. :-)

Meanwhile, there is a little movie up now to show the workings of the Pig in
a Poke code. You can get to it through www.valar.com or directly to it with
http://www.valar.com/single

Everyone have a great holiday tomorrow.

John Esak
Visit The FP Room www.valar.com/yuag7 24/7

P.S. - A couple people also asked me why I didn't use the @vr system
maintained variable to test the version number and set the lookup key
accordingly. The @vr variable did not come into existence until 5.0, so it
is quite unusable as yet. When 5.6 is released in July (or whenever), it
will become pretty useful right away! For my little "pig" code though, in
order to make it backward compatible to 4.8, I had to use a 2 character
variable, l (el).... I hated to do this, because this is something I simply
NEVER do on a CALL table. Using only unique declare'd variables on a CALL
table is the only way to ensure that they are *completely* portable from
file to file. 2 character dummies on a CALL may conflict with the same
variable defined as global (,g) that you might be using for other purposes
in that processing table set.  Hated to have to use the "l", but had no
other option. On the astonomically thin channce that you are limited to
version 4.8, *and* have a file in which you want to use the "pig", *and*
that file has the single letter variable "l" defined in it, *and* it is a
global variable, *and* it has a value that you don't want changed by the
"pig" call... Well, on that incredibly strange possible set of circumstances
being true... deal with it! :-)  Change the "l" to something else that won't
conflict.  :-) I've stopped losing sleep over it. :-) :-)