For use in dclerk.... :-)<br><br>Since there is relatively little difference between load times with dclerk and rclerk on today's computers I see little reason to use rclerk since I am not a third party developer protecting my code on customers computers by only installing tok files, which is about the only plus for rclerk now I believe.<br>
<br>Ken<br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 10:35 AM, Joe Chasan <span dir="ltr"><<a href="mailto:joe@magnatechonline.com" target="_blank">joe@magnatechonline.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
then again, why allow for this "dynamic" syntax in cabe?<br>
<br>
-joe<br>
<br>
On Thu, Feb 14, 2013 at 10:30:38AM +1100, Ken Cole wrote:<br>
> Joe,<br>
><br>
> Look at it this way, since variables must be pre-defined in filePro, so<br>
> they have a size and edit in the token table (tok file), that is just the<br>
> way filePro has always worked, how else can rclerk use this syntax except<br>
> to re-tokenise each and every time it loads which means it would actually<br>
> be dclerk? :-)<br>
><br>
> If the token table concept didn't exist we could have array's with dynamic<br>
> length as well but we don't! :-(<br>
><br>
> Cheers<br>
><br>
> Ken<br>
><br>
> On Thu, Feb 14, 2013 at 10:24 AM, Joe Chasan <<a href="mailto:joe@magnatechonline.com">joe@magnatechonline.com</a>>wrote:<br>
><br>
> > i understand why its happening, i just think its poor implentation if<br>
> > fp allows for this feature but it is only available in dclerk.<br>
> ><br>
> > -joe<br>
> ><br>
> > On Thu, Feb 14, 2013 at 10:19:01AM +1100, Ken Cole wrote:<br>
> > > Joe,<br>
> > ><br>
> > > I see this as the "normal" state for compiled/tokenised code as is<br>
> > required<br>
> > > for rclerk.<br>
> > ><br>
> > > Since dclerk technically in memory re-tokenises every time you run the<br>
> > > processing table, basically the only difference between rclerk and<br>
> > dclerk,<br>
> > > I fully understand why dclerk works and rclerk doesn't until<br>
> > re-tokenised.<br>
> > ><br>
> > > rclerk has created the token table (tok file) entry for test_field the<br>
> > last<br>
> > > time it was tokenised and that definition will stay in the token table<br>
> > > until re-tokenised.<br>
> > ><br>
> > > The code you used is a short cut definition, not dynamic definition,<br>
> > unless<br>
> > > you are using dclerk.<br>
> > ><br>
> > > I don't see this as a bug or poor design.<br>
> > ><br>
> > > Regards<br>
> > ><br>
> > > Ken<br>
> > ><br>
> > > On Thu, Feb 14, 2013 at 9:26 AM, Joe Chasan <<a href="mailto:joe@magnatechonline.com">joe@magnatechonline.com</a>><br>
> > wrote:<br>
> > ><br>
> > > > consider the following line of code:<br>
> > > > declare local test_field(len(1),edit(1))<br>
> > > ><br>
> > > > then you code some routines around test_field and figured you have the<br>
> > > > system beat, you won't have to change dummy field length/type if field<br>
> > > > #1 changes at all. great for reusable code, libraries, etc, or so I<br>
> > > > thought.<br>
> > > ><br>
> > > > today i changed field length.<br>
> > > ><br>
> > > > in define processing, if you press <F6><L> it correctly reports the<br>
> > > > current field length/type of test_field<br>
> > > ><br>
> > > > BUT - if you do not save the processing table and retokenize, rclerk<br>
> > > > still has the old length/type (dclerk works).<br>
> > > ><br>
> > > > If this construct is not adjusted at runtime (even with quickstart),<br>
> > > > what is the point of this "feature"?<br>
> > > ><br>
> > > > Bug? Poor design?<br>
> > > ><br>
> > > > (5.6.11/sco - reproducable on sco5 and sco6)<br>
> > > ><br>
> > > > --<br>
> > > > -Joe Chasan- Magnatech Business Systems, Inc.<br>
> > > > joe - at - magnatechonline -dot- com Hicksville, NY - USA<br>
> > > > <a href="http://www.MagnatechOnline.com" target="_blank">http://www.MagnatechOnline.com</a> Tel.(516) 931-4444/Fax.(516)<br>
> > > > 931-1264<br>
> > > > _______________________________________________<br>
> > > > Filepro-list mailing list<br>
> > > > <a href="mailto:Filepro-list@lists.celestial.com">Filepro-list@lists.celestial.com</a><br>
> > > > Subscribe/Unsubscribe/Subscription Changes<br>
> > > > <a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
> > > ><br>
> > > -------------- next part --------------<br>
> > > An HTML attachment was scrubbed...<br>
> > > URL:<br>
> > <a href="http://mailman.celestial.com/pipermail/filepro-list/attachments/20130214/63d4a4ae/attachment.html" target="_blank">http://mailman.celestial.com/pipermail/filepro-list/attachments/20130214/63d4a4ae/attachment.html</a><br>
> > > _______________________________________________<br>
> > > Filepro-list mailing list<br>
> > > <a href="mailto:Filepro-list@lists.celestial.com">Filepro-list@lists.celestial.com</a><br>
> > > Subscribe/Unsubscribe/Subscription Changes<br>
> > > <a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
> > ><br>
> > --<br>
> > -Joe Chasan- Magnatech Business Systems, Inc.<br>
> > joe - at - magnatechonline -dot- com Hicksville, NY - USA<br>
> > <a href="http://www.MagnatechOnline.com" target="_blank">http://www.MagnatechOnline.com</a> Tel.(516) 931-4444/Fax.(516)<br>
> > 931-1264<br>
> ><br>
--<br>
-Joe Chasan- Magnatech Business Systems, Inc.<br>
joe - at - magnatechonline -dot- com Hicksville, NY - USA<br>
<a href="http://www.MagnatechOnline.com" target="_blank">http://www.MagnatechOnline.com</a> Tel.(516) 931-4444/Fax.(516) 931-1264<br>
</blockquote></div><br>