chain from @wlf

Joe Chasan joe at magnatechonline.com
Fri Apr 15 14:11:20 PDT 2005


On Fri, Apr 15, 2005 at 04:50:07PM -0400, Kenneth Brody wrote:
> Quoting Joe Chasan (Fri, 15 Apr 2005 14:35:00 -0400):
> 
> > 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...
> 
> In the general sense, there isn't really a problem with CHAIN in @WLF.
> That said, I can see a scenario that might confuse filePro...
> 
> (Note that this is just off the top of my head.  I have not verified
> any of this.)
> 
> If the event you are triggering is on a screen which was reached via a
> processing command (such as SCREEN or POPUP UPDATE), then when you save
> that screen, filePro will continue processing following that command.
> If you have pulled the rug out from under filePro, I could see problems
> that could occur.
> 
> For example, you have @KEY processing, which hits a SCREEN command in
> the middle of line 123.  While updating that screen, you hit @WLF on a
> field which contains a CHAIN command.  You have now replaced the input
> processing table with the new input table.  You continue along your
> merry way, until you SAVE that screen.  filePro will now go back to
> the middle of line 123 to continue processing following the original
> SCREEN command.  Of course, at this point, "the middle of line 123" is
> something completely different, or not existent at all.

then you are saying it should work - i'm certain we're at a point where
we have a bug then as clerk is getting lost in the chained-TO table, not
the original one that did the first chaining.

on return i accept the fact that clerk will execute top down and i use 
dummies to restore to where i chained from as close as possible, i 
accept responsibility (as the filepro programmer) for the case you 
mention but that is not the problem i am having.

--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
-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


More information about the Filepro-list mailing list