End and the syntax parser

[Richard Kreiss]

> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
[mailto:filepro-
> list-bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of John
Esak
> Sent: Tuesday, December 22, 2009 12:33 PM
> To: filepro-list at lists.celestial.com
> Subject: RE: End and the syntax parser
> 
> 
> <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,

The other piece we once talked about with long variables was,  display and
highlight , and when <enter> is pressed, copying it to the program line.
This would save typing really long variable names and possibly making a
typo.


Richard


> 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
> >
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list