Evaluating opinions - FilePro Error Messages

[Jay R. Ashworth]

On Thu, Jun 03, 2004 at 04:41:30PM -0400, Nancy Palmquist wrote:
> 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 concur entirely.  That's not the proper solution.

> 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.

Why is it well known, Nancy?  Does the manual say not to do it?

(I really don't know; I don't have a copy handy.)

But since, as I noted, it would take about 3 lines in the sources to
fix it, condoning it doesn't seem the best solution either.

> 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.

And that happens.  But, clearly, you can see what I mean when I'm not
happy with error messages that *appear* to know what's wrong.

Much less saying it's a syntax error, when it's not.

> 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.

You *bet*.

> 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.

My impression has always been that fptech's corporate opinion of our
idea, going back at least three owners now, was roughly equivalent to
John's.  Ken, Wally and Bud are all listening here.  If they think the
ideas are useful no doubt they can find a way to use them.

I see no motion in that ocean.

I do see sales literature trumpeting the actions of school boards who
are likely to get sued really badly for what fpTech thinks is neat...

but I won't start that.

> 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.

My point there was merely to observe that John's steadfast refusal to
characterise fP as an application development toolset -- a product
written and maintained *primarily* for commercial developers who are
using it to make a living -- has much light to shed upon his opinions
of my opinions.

IMHO.

> It has become fashionable to design a new application with the newest
> and greatest tools move all your data and retrain all your employees.

Yeah.  Idiots.

Ask an Allied Van Lines agent about the replacement for CAMIS.

> 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.

Alas, there are many thinsg that remain broke... and ain't gettin fixed.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson