Strange pkeepin'
Nancy Palmquist
nlp at vss3.com
Thu May 8 06:53:36 PDT 2008
Bruce Easton wrote:
> I'm seeing some strange browse pkeep behavior today on
> Windows filepro 5.0.14. I don't think the couple of items
> I see in the release notes about pkeep from 5.0.14 on describe
> what I am seeing. Also, I'm pretty sure that I've coded
> the exact same under Unix and did not see the behavior there.
>
> I'll first post code where everything works as expected
> (subroutine 'clearm' [not shown] just deletes records for
> session out of file 'mymarkfile'):
>
> 595 ------- - - - - - - - - - - - -
> @wbl4 ? If: 'sets kn(8,.0) to one-up # for marking file
> Then: gosub getctrl '(used as marking session key)
> 596 ------- - - - - - - - - - - - -
> ? If: 'browse spec
> Then: bt="(brw=12 xkey=xm prc=filmk show=pkeep fill=asc)"
> 597 ------- - - - - - - - - - - - -
> ? If:
> Then: bu="[Mark Type of Document]"
> 598 ------- - - - - - - - - - - - -
> ? If:
> Then: bv=" *mk *2"
> 599 ------- - - - - - - - - - - - -
> ? If:
> Then: ky(60,*)=""
> 600 ------- - - - - - - - - - - - -
> rptbrw ? If:
> Then: cls("22"); showctr("23") "\r M \r-Mark \r X \r-Exit"
> 601 ------- - - - - - - - - - - - -
> ? If: 'MAIN BROWSE for marking
> Then: lookup brfil = myfile@ k=ky i=A -ng b=(bt&bu&bv)
> 602 ------- - - - - - - - - - - - -
> ? If: not brfil 'data missing fr supporting file
> Then: beep; errorbox "Docs missing"; clearb; screen ,4
> 603 ------- - - - - - - - - - - - -
> ? If: @sk eq "BRKY" or @bk eq "X" 'operator exiting
> Then: gosub clearm; clearb; screen ,4
> 604 ------- - - - - - - - - - - - -
> ? If: @bk eq "M" 'operator marking record in browse
> Then: gosub markit; goto rptbrw
> 605 ------- - - - - - - - - - - - -
> ? If: 'future xkey vals tested down here
> Then: goto rptbrw 'should now never reach here.
> 606 ------- - - - - - - - - - - - -
> markit ? If: '**** subroutine for marking one record
> Then: 'triggered from @bk="M" on browse
> 607 ------- - - - - - - - - - - - -
> ? If:
> Then: hk(14,*)=kn&brfil(1)
> 608 ------- - - - - - - - - - - - -
> ? If:
> Then: lookup mrkfil = mymarkfile@ k=hk i=B -nx
> 609 ------- - - - - - - - - - - - -
> ? If: mrkfil
> Then: return 'already marked
> 610 ------- - - - - - - - - - - - -
> ? If: 'make a marking record
> Then: lookup mrkfil = mymarkfile@ r=free -ep
> 611 ------- - - - - - - - - - - - -
> ? If:
> Then: mrkfil(1)=kn; mrkfil(2)=brfil(1)
> 612 ------- - - - - - - - - - - - -
> ? If:
> Then: return
> 613 ------- - - - - - - - - - - - -
> filmk ? If: 'fill (drop) processing for browse above ******
> Then: '(tests existence of marking record)
> 614 ------- - - - - - - - - - - - -
> ? If:
> Then: mk(1,*)=""; hk=kn&brfil(1)
> 615 ------- - - - - - - - - - - - -
> ? If:
> Then: lookup thisbr = mymarkfile@ k=hk i=B -nx
> 616 ------- - - - - - - - - - - - -
> ? If: thisbr
> Then: mk="M"
> 617 ------- - - - - - - - - - - - -
> ? If:
> Then: end
> 618 ------- - - - - - - - - - - - -
>
> This all works fine. The way I used to write these procedures
> included a 'close mrkfil' - for here that would be before
> the return on line 612. In this case when I try to close
> the marking file, pkeep is no longer able to keep its place,
> and every time the browse is re-executed at 'rptbrw', the
> browse pointer is at position of the original key.
>
> I started to think that since I was closing the file
> that is also used in the drop processing (to show the
> status of what was just marked), that I might be
> confusing clerk there.
>
> But even when I kept the 'close mrkfil' at 612 before
> the return and removed the 'prc=filmk' from the browse
> specification, it still would return the browse pointer
> to the beginning of the original key after each 'M'
> keypress on the browse. So even though I'm not closing
> the file that I'm browsing, closing some other file,
> even if not called in drop processing is affecting pkeep.
>
> I guess I can live without the close (although there is
> also a routine to delete marks and I really would like
> to be able to at least close there).
>
> I'm sure that I was doing it that way before in Unix
> (although it probably was an earlier 5.0 filepro).
Bruce,
I see some logic that changes data in the file you are browsing. Is it changing
the data that is used to index the file?
That will cause the kinds of issues you describe. Since you move your position
in the index when you change the data, filePro may just start you back at the
beginning instead of trying to figure out where you are now.
I would make the key a variable and load it with the new key when a record is
managed, then just use that key and refresh the browse.
Nancy
--
Nancy Palmquist MOS & filePro Training Available
Virtual Software Systems Web Based Training and Consulting
PHONE: (412) 835-9417 Web site: http://www.vss3.com
More information about the Filepro-list
mailing list