Evaluating opinions - FilePro Error Messages

[Nancy Palmquist]

Now this was just too good to pass up, a John, Mark and Jay discussion.

I do want to say in preface that all filePro programmers can relate to
issues with
filePro errors and misdirection.  It is certainly frustrating but I
wonder how 
much better it can be expected to behave.  But first let me respond:

Fairlight wrote:

> Tecnically yes.  However, how hard would it be to actually put code in fP
> that prevents one from modifying the key field(s) of the lookup index to
> prevent people from making the mistake at all?  I shouldn't think very
> difficult, since it knows exactly what fields it's dealing with.

Never support this in a million years.  After I attach to a record with
a lookup, 
why should it not allow me to change a KEY field any way I want.  How
does it know what
I will do next?  You are asking it to change a fundemental feature, to
protect bad logic.

I can never support that.  The issue with using GETNEXT or GETPREV in
any loop that changes
the key or deletes records is a well known NO NO in the filePro
programming world.  NEVER 
EVER use GETNEXT or GETPREV in these situations.  

Some errors come across as misdirection because they are caused by bad
logic.  The syntax checker is not 
designed to find logic errors.  It will not show you "RETURN without
GOSUB" errors you have to test to 
find those errors because until you process the lines in sequence they
are not evident to the software.

---------------------------

It was certainly nice to see Mark act as a "peacemaker".  I bet that
felt good.

MY Final words:

I spent a few minutes trying to figure this error out.  A syntax error:

handle = open(fn,"cwt")
	 ^
The caret did not like the open part of this.  The handle is defined,
the fn name is defined, which were
the first things I changed and checked.  Finally, I searched the file
for "open(" and found
a line that declared open(3,yesno)

Now is the error wrong, misdirecting, or is it right.  It would have
been nice if the error had said 
there was a conflict or duplicate use of the OPEN thing.

In my own defense, I was kludging together routines from a few files and
did not realize the OPEN declare was
in one of the routines.

I would suggest a way to see all DECLARED VARIABLES, labels, Lookup
aliases, Field Headings, 
Selection sets, array names, (whatever I forgot also) in one alphabetic
list, like the declares are listed.  Include a
code saying which thing it is.  That would make it easier to check for
conflicts.

In defense of Jay, I feel your frustration when I run up against an
error that does not give me the exact information, but 
I enjoy the puzzles and if anyone would like to document situations
where the filePro programmers could do better, 
please send those to filePro support or post them to the wish list. 
Airing them here does not improve your chances
to get any resolution to the situation.

In defense of John, I think I know filePro is a "killer app/development
tool" and can write circles around most others.  It is fast.  
Development is quick.  It can handle a lot of data and get quick
responses.  The shortcomings are legacy issues.  
The GUI solutions was designed to allow existing users to add it and use
it without investing in a new application.  

It has become fashionable to design a new application with the newest
and greatest tools move all your data and retrain all your 
employees.  This is not possible to many customers because of cost. 
They want to use what they have as long as they can.  I find
that admirable.  Just because it can be changed does it mean it has to
be changed.  
Whatever happened to the old adage "If it ain't broke don't fix it."  I
don't see any problem with filePro continuing into the 
future.  I am hopeful and find that I can still design a great app with
the filepro tools. 

Nancy
-- 
Nancy Palmquist 
Virtual Software Systems
PHONE: (412) 835-9417			Web site:  http://www.vss3.com