End and the syntax parser

[John Esak]

<I removed all the quoted junk... Except what I'm commenting about. Sorry.
It was getting too loooong and messy.

But, Richard. I don't see by your explanation how Ken's first suggestion
would mess you up in any way.  He saying that you can't (or shouldn't) use
END and other KEYWORDS for anything other than their intended use, like
alias's, labels, and so on.  I don't think this would screw you up.  

I like the attaching an auto table at time of saving processing, maybe as a
new key in the Function section. It would have to be there before the save
is pressed.

And since we're all jumbling wishlist things ab out syntax, etc. together...
I'll muddy things further with a request that would really help me... I
would like to be able to see a full (page-able) list of all 2-char dummies,
long variables and even current rile (or switchable-file) real fields in the
debugger with their current value at the time the new button is pressed.
Now, you must type in each field at the (e)xpression prompt one at a time.
Wouldn't it be cool if you could see the contents of all the variables at
once?  Yes, I'll answer my own question.  :-)

John


> Ken,
> 
> Syntax check of using a reserved work for a variable - Yes.
> 
> The first suggestion would cause syntax warnings on most of 
> my processing
> tables.
> 
> I have programming where sub-routines are placed at the end 
> of my processing
> tables.  Some are accessed only once or rarely when an error 
> occurs.  I have
> found it more convenient to keep these at the bottom of a 
> processing table
> after any @once or @entsel processing.  
> 
> @once ends with an <end>.  Also, some of my looping routines 
> which use a
> goto, have an end statement so if the process fails, it doesn't fall
> through.  Again this would cause problems.
> 
> I will add to the syntax check fix request, the ability at 
> the time of the
> syntax check or when entering a processing table, to select 
> an alternate
> auto process table.  This could also be used at tokenization 
> time.  I have a
> number of instances where I have processing tables for both 
> input and output
> which use an alternate auto table or none at all.  It is a 
> unnecessary for
> me to see that dummy field conflict errors in auto processing 
> when I am not
> using that table.
> 
> Would any of you like an option to display the dummy fields 
> and/or long
> variables defined in your auto process table when working on 
> another table?
> This would possibly eliminate the duplicate casting of 
> variables.  Yes, if
> one has more the a one use development license, one can open 
> another session
> and view the auto table.  But that uses a licensed session, 
> which may not be
> available.
> 
> 
> Richard Kreiss
> GCC Consulting
> rkreiss at gccconsulting.net
>   
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>