readline() strangeness on 4.8.10D4

[Kenneth Brody]

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.

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com