Switching to update mode from @ENTSEL
John Esak
john at valar.com
Tue Jul 10 01:08:42 PDT 2007
Hey Barry,
Just a quick follow-up note on the message you left Ken. Yes, it is cool to
do some non-writing processing and then do a pushkey "x" so that the @entsel
will push the @keyX for you where you can do the actual writing to the
current record... but, this puts you back into the same old syndrome of
locking the record. It is always my goal to do as much work as possible
*without* locking the current record... so I do the same thing a tiny bit
differently ... including the lookup to the current record for the actual
post... this way, you are only locking the record for the much briefer time
of the lookup -p to the "write alias" bit of code... and not the whole @keyX
time frame. I do it like this: (and there is even a new feature in 5.x that
mimics my little routine... but I don't actually use it... :-)... I'm old
fashioned... I still do it my old way. Like this:
In the INPUT table, do the following to get you to @entsel with a global
variable set...
then: gg(6,,g)="dokeyX"
then: end
@entsel if: gg eq "dokeyX"
then: gosub dokeyX; gg=""
then: ...
then: end
dokeyX if:
then: lookup self=filename r=@rn -p
then: self(4)="something"; blah... blah...; write self; return
I think this is slightly better than calling the @keyX which runs through
automatic, etc., to do its thing and therefore keeps the record locked much
longer. Of course, if you've got lots of legacy @keys just hanging around
it's much easier to use them... but you could also just encapsulate them in
a gosub called dokeyX anyway. :-)
As we all know, a big part of the game is to do as much as possible without
locking the current record. So, we do all our browses into other files,
printing of forms, reports, etc., all with some form of employing @entsel
instead of @keys. In fact, mostly now, I just use the @key to set the
global variable which tells @entsel what to do.
John
P.S. - Like I say, I'm guessing Ken or Ron might have seen some of my global
var/dokeyX code somewhere, maybe an article or program or something, because
during 5.0.x?, a "dokeyN" was added. It is couched more as having the
ability to intercept the factory @keys like "B", "H" and so on... but it has
this other utility as well... but even so, I haven't actually employed it
yet.
(Hey, maybe the programmers never actually saw my dokeyX coding... (although
it was in a an article about @entsel) who knows... it might just be an odd
coincidence that they called the new feature "dokey" also. It just makes me
happy to think they are looking at developer code and adding features based
on some of it to make our lives easier... like we used to do in the early
days of The small Computer Company. For a few years in there somewhere it
seemed like that practice slowed down a bit. Hopefully, it's back for good
now? It is after all a very valuable way to add some of the new features to
a product... the developers like us come up with the problems and the
solutions, so why not make the best use of our late night work!
Take care,
John
> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> Behalf Of John Esak
> Sent: Monday, July 09, 2007 7:56 PM
> To: Filepro-List at Lists. Celestial. Com
> Subject: RE: Switching to update mode from @ENTSEL
>
>
> Yup.
>
>
> > -----Original Message-----
> > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> > Behalf Of Barry Wiseman
> > Sent: Monday, July 09, 2007 12:31 PM
> > To: Filepro-List at Lists. Celestial. Com
> > Subject: Re: Switching to update mode from @ENTSEL
> >
> >
> > (top-posted for John)
> >
> > Thanks, John! I suspected I was simply experiencing a little
> > brain freeze on this.
> >
> > So you're saying, instead of
> >
> > ::1=x:
> > do
> > ::lookup myrec = myfile r=@rn -ep:
> > ::myrec(1)=x:
> > ::write myrec:
> >
> > Should do the trick.
> >
> > John Esak wrote:
> > > Barry,
> > > I do just about everything from @entsel... still there are no
> > good ways to
> > > prevent broken header-detail ties if things go awry. However,
> > instead of
> > > the posting to a temporary array, have you thought of doing a
> > lookup to the
> > > record your standing on? It may be locked, but *you* own the
> > lock, so it
> > > opens up some possibilities.
> > >
> > > John
> > >
> > >
> > >> -----Original Message-----
> > >> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > >> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> > >> Behalf Of Barry Wiseman
> > >> Sent: Monday, July 09, 2007 12:05 PM
> > >> To: filePro list
> > >> Subject: Switching to update mode from @ENTSEL
> > >>
> > >>
> > >> I'm trying to rewrite some old programs that do all their work
> > >> standing on a locked
> > >> record (everything hangs off initial @KEY triggers). I want to
> > >> instead have as much
> > >> as possible happen within @ENTSEL processing so that the record
> > >> is not locked.
> > >>
> > >> However, the tree of user interaction runs deep -- various
> > >> master/detail browses and
> > >> their respective options, some of which require updating the
> > >> master record and some
> > >> don't.
> > >>
> > >> Is there some graceful method (that hasn't occurred to me) of
> > >> dropping into update
> > >> mode at any arbitrary point deep within @ENTSEL processing? I
> > know I can
> > >>
> > >> ::pushkey "U"; end:
> > >> @UPDATE::' do whatever:
> > >>
> > >> but then I need flags and a jump table to know why I came there
> > >> and it all gets
> > >> pretty messy.
> > >>
> > >> My other thought was to create an array of numfield(-) elements,
> > >> and write all
> > >> updates there instead of to the current record. On exit, a
> > >> single @UPDATE routine
> > >> can loop thru the array, copying whatever's "dirty" into the
> > >> appropriate fields. But
> > >> this type of deferred posting seems rife with possibility for
> > >> disaster that would
> > >> leave transactions corrupted and records out of balance.
> > >>
> > >> Any suggestions welcome.
> > >>
> > >>
> > >> -----------------------------------------------------------------
> > >> Barry Wiseman barry at gensoftdes.com
> > >> Genesis Software Designs, Inc. Voice: (212) 889-9191
> > >> 55 West 45 Street, New York, NY 10036 Fax: (212) 889-1589
> > >> -----------------------------------------------------------------
> > >>
> > >> _______________________________________________
> > >> Filepro-list mailing list
> > >> Filepro-list at lists.celestial.com
> > >> http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >
> > >
> > >
> >
> > --
> > -----------------------------------------------------------------
> > Barry Wiseman barry at gensoftdes.com
> > Genesis Software Designs, Inc. Voice: (212) 889-9191
> > 55 West 45 Street, New York, NY 10036 Fax: (212) 889-1589
> > -----------------------------------------------------------------
> >
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
More information about the Filepro-list
mailing list