declare variable - bug or poor design?

[Ken Cole]

Joe,

I see this as the "normal" state for compiled/tokenised code as is required
for rclerk.

Since dclerk technically in memory re-tokenises every time you run the
processing table, basically the only difference between rclerk and dclerk,
I fully understand why dclerk works and rclerk doesn't until re-tokenised.

rclerk has created the token table (tok file) entry for test_field the last
time it was tokenised and that definition will stay in the token table
until re-tokenised.

The code you used is a short cut definition, not dynamic definition, unless
you are using dclerk.

I don't see this as a bug or poor design.

Regards

Ken

On Thu, Feb 14, 2013 at 9:26 AM, Joe Chasan <joe at magnatechonline.com> wrote:

> consider the following line of code:
> declare local test_field(len(1),edit(1))
>
> then you code some routines around test_field and figured you have the
> system beat, you won't have to change dummy field length/type if field
> #1 changes at all.  great for reusable code, libraries, etc, or so I
> thought.
>
> today i changed field length.
>
> in define processing, if you press <F6><L> it correctly reports the
> current field length/type of test_field
>
> BUT - if you do not save the processing table and retokenize, rclerk
> still has the old length/type (dclerk works).
>
> If this construct is not adjusted at runtime (even with quickstart),
> what is the point of this "feature"?
>
> Bug?  Poor design?
>
> (5.6.11/sco - reproducable on sco5 and sco6)
>
> --
> -Joe Chasan-                           Magnatech Business Systems, Inc.
> joe - at - magnatechonline -dot- com   Hicksville, NY - USA
> http://www.MagnatechOnline.com         Tel.(516) 931-4444/Fax.(516)
> 931-1264
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20130214/63d4a4ae/attachment.html