chain from @wlf

[Joe Chasan]

On Fri, Apr 15, 2005 at 02:49:53PM -0400, Fairlight wrote:
> The honourable and venerable Joe Chasan spoke thus:
> > fp 5.0.14, unix.
> > 
> > Is anyone using chain command successfully from @wlf while within
> > update on a record within *clerk?
> > 
> > I have a table that works by itself, works when chain'ed from @key,
> > yet if i chain to it from within update on a record from @wlf, within
> > the chain'ed to table clerk is completely confused as to what line #'s
> > it should be executing, going to lines that are never referenced,
> > executing partial subroutines, or giving SegV's.  
> > 
> > I had though this was working for a while, I don't see in docs anywhere
> > that says can't chain from within update...
> 
> Disclaimer:  I have not seen the fP source code, and these are educated
> guesses.
> 
> That said, it seems like a fairly safe assumption from a logical point of
> view that you're confusing the table handler by -where- you're triggering
> it.
> 
> I was under the impression that chain was used primarily in the early days
> to get around table length limitations.  I've been told that it basically
> -replaces- the table that made the chain call with the target of said call.
> 
> If you have event triggers like @key, @wlf's, @wef's, etc., and you
> -replace- the table in memory, you were at a place in memory while
> executing those, and those places just got overwritten--or at the very
> least the pointers are no longer to the correct locations for various
> events.  So any WHEN processing events you had coded should, from a logical
> point of view, completely vanish and become null and void.  I'd say it
> might make sense if it was programmed to pick up on new WHEN processing in
> the new table, but I somehow don't think they anticipated someone chaining
> out of an event and nuking all their triggers in event-handler.
> 
> Best guess, but I think you're probably corrupting memory by using it for
> something it was probably never intended for.
> 
> It'll be interesting to see Ken's answer, though.

so would i.

as a consultant who lots of time has to work with programs/tables/etc
written by other people, sometimes its advantageous to work in a "clean"
environment that call/chain offer - when you have a 1500 line table with
15 screens and 80% of the 2 letter dummies already used, it is certainly
a lot less work to be able to modularize what can essentially be a
stand-alone program in its addition than to retrofit it into such a limited
environment.  

Call is too limited in fact that many tools one likes to use for interactive
@wlf processing commands don't work, can't nest calls, etc, so once in a 
while I like to play with chain for this.

it is easy enough to set long dummies to whatever tables/screen/fields
you were in before/after chain so that you can transparently go back
exactly where you started from.

--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
-Joe Chasan-                      Magnatech Business Systems, Inc.
joe at magnatechonline.com           Hicksville, NY - USA
http://www.MagnatechOnline.com    Tel.(516) 931-4444/Fax.(516) 931-1264