Strange pkeepin'
Bruce Easton
bruce at stn.com
Thu May 8 07:55:13 PDT 2008
Nancy Palmquist wrote Thursday, May 08, 2008 9:54 AM:
> 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
>
Actually, Nancy, there is no code that changes the key of
the browse file, nor does it change any data in the browse
file. If you still see something that changes either of
these from the code above, please point out the line -
maybe I am missing something.
The code activated by the @bk key "M" here changes
data in another file that is read by the drop processing
of the browse. It's the 'close' on that other file that
is affecting the re-positioning of the browse file - just
by making a free record in the other file and then closing
that free record (not the browse file) affects the browse
behavior.
As I said, at first I thought it was because I referenced
that other file in the drop processing. But when I remove
the 'prc=filmk' so that there is no drop processing called,
the 'close <otherfile>' still affects the browse pointer.
But at least is seems to be working OK on this version
without the close. I just don't like doing a series of
deletions for instance (not shown in the code above)
where I don't terminate it with a
'close <filebeingdeletedfrom>'.
Bruce
Bruce Easton
STN, Inc.
More information about the Filepro-list
mailing list