readline() strangeness on 4.8.10D4

[Roger Cornelius]

On 12/17/2008 15:33, GCC Consulting wrote:
> 
> 
> > -----Original Message-----
> > From: filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
> >
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com]
> On
> > Behalf Of Roger Cornelius
> > Sent: Wednesday, December 17, 2008 3:00 PM
> > To: Kenneth Brody
> > Cc: filepro-list at lists.celestial.com
> > Subject: Re: readline() strangeness on 4.8.10D4
> > 
> > On 12/16/2008 23:29, Kenneth Brody wrote:
> > > Quoting Roger Cornelius (Tue, 16 Dec 2008 17:30:43 -0500):
> > >
> > >> Filepro 4.8.10D4 on SCO OSR507
> > >>
> > >> I'm seeing strange behaviour from readline(), which I haven't had a
> need
> > >> to use before now.  Or maybe it's len() or call processing or the
> > >> debugger that's the problem.
> > >>
> > >> - I'm using a called table via "call noauto"
> > >> - In auto processing I have field kz(12,*)
> > >> - In called table I have field kz(64,*)
> > > [...]
> > > ... readline() works, but len(kz) and the debugger show 12 characters
> ...
> > > [...]
> > >
> > > Sounds like an issue with len() and the debugger, as readline() is
> > > returning the proper 64 characters.
> > >
> > > [...]
> > >> And also:
> > >>
> > >> - readline() doesn't like it when it's arguments are variables with
> long
> > >>   names.  At least I get a syntax error when I try to save the table.
> > >>   writeline() seems to work fine with long name variables.
> > >>
> > >> Since we're on an old fp version, can I assume these issues have
> already
> > >> been reported and fixed?  If so, in what version?
> > >
> > > As noted in the 4.8.12 readme:
> > >
> > > All
> > >     READ()/READLINE() now accept long-named variables as the second
> > >     parameter.
> > >
> > >> Am I going to have problems reusing vars which exist in auto processing
> > >> even though I'm using "call noauto"?
> > >
> > > Define "problems".
> > >
> > > By using CALL NOAUTO, you are telling filePro that the CALLed table is
> > > to not share the dummy fields which may be defined in auto processing.
> > > In this case, the CALLed table's "kz" field is local to that table, and
> > > not the one already defined in auto, which would have happened with a
> > > "normal" CALL.  The same holds true for all other dummy fields.
> > 
> > By "problems", I mean could vars used in both auto and called processing
> > stomp on each other even though I'm using "call noauto"?  This, given
> > the fact that the debug mode "F" command, from the called table, shows
> > the length and value of the field as defined in auto processing and not
> > called processing.  If there's a bug that allows debug mode to see the
> > auto processing version of the var, what's to say the bug doesn't also
> > allow other areas of processing to see the auto version of the var?
> > 
> > To put it another way, if we know the "auto processing vars not visible
> > in call noauto processing" concept is broken in debug mode, how can we
> > know if it's not also broken in other areas?
> > 
> > Does that make sense?
> > --
> > Roger Cornelius            rac at custom-mobility.com
> 
> I'm getting in here a bit late.  But, once the auto processing table has
> run, any variables set there are set.  Defining variables either in the
> current table (input.prc) or in a called table will be in conflict what is
> defined in the auto processing table.
> 
> In fact, when does a syntax check on a table, it will tell you if the
> variable has already been defined in the auto processing table.
> 
> Is there any logical reason for using the same variable kz in both tables?

Please reread the thread and note "call noauto" and it's behaviour as
documented in the manual.

In my case there isn't any reason to re-use variable names.  I was
pointing out that filepro does not appear to be behaving as documented.
However, I can image situations where re-using vars would be necessary.
If all two char vars are already in use, this would be necessary since
in this case I'm using readline() which does not support long var names
in this version of filepro.
-- 
Roger Cornelius            rac at custom-mobility.com