fp 6.0

[Fairlight]

Y'all catch dis heeyah?  GCC Consulting been jivin' 'bout like:
> I seem to recall back in the 4.0 days that there was discussion of
> breaking the 80X24 line screen limit.

There's been discussion of a great many things in the decade or so since I
became aware of filePro.  There's been a lot less actually done.

> What was being bandied about was allowing the screen to scroll down for
> more then 24 line.  It would be nice to have, say, a 60 line limit to the
> screen allowing it to match a from page.

I subscribe to a tenet of perl's design philosophy:  "No artificial
limits."  There shouldn't be -any- limit.  You should be able to scroll
vertically or horizontally if the screen was designed to be larger than
either aspect of your present terminal--or it should simply warn you that
it's designed for X x Y size terminal.  Either way.

Likewise, I'd do away with 32K limits on dummy fields (malloc exists
for a -reason-), edit limits (ditto), and a host of other limitations.
Indexes...you want more, you make more.  Expand them out so you can have
multi-character index names.  If fP can tell the difference between 'eq'
the opearand and 'eq' the variable in a conditional, it can interpret
whether an index as i= in a lookup is meant to be variable (they should
be made so anyway, as I stated in my first post on the matter) or whether
they're literal.  It could be as simple as denoting i=!AB! to specify it
rather than (AB) (which would presumably eval as a variable)..  Whatever
works.

Artificial limits are the biggest frustration any developer faces--when
you know it could be capable of something if someone would just expend the
effort to make it happen.

But again, we probably get into Legacy Land.  Sometime, they're going to
have to Just Get Over It, bite the bullet, and break compatability in some
areas if they want to maintain any kind of -meaningful- forward momentum.  

> I don't recall which one of the principles, at the time, I suggested this
> to, but his comment to me was "how do we do that".  My answer was, I
> don't know, but you're the programmers".

*snicker*  And quite right you were.

> One thing I would love to have is the ability to import from processing
> tables anywhere on my system; not just from the current filePro directory
> I am working in.  Also, I would like to be able to specify which lines
> I want to import not just the whole table.  Now, I do have a library of
> routines I can import when necessary but sometime I need only a piece I
> did for another client.

ABE=ASCII and judicious use of gvim?

> Many of the items posted should go to the WishList.

Funny thing about the wishlist.  Much ado about it when it was supplied
as available for submissions and there was this great harvest for ideas.
But everyone that's talked to me about it seems to wonder who (if anyone)
actually reads it--and what's more, how to look at what's already been
submitted in order to see what's on the table (synergy is a good thing)
and also avoid redundant effort.  AFAICT, there's no way to view it.
Of course, that could work to someone's advantage.  If you can't see
something's in high demand (with possible voting tallies accompanied by
email addresses of those who seconded [etc.] the motion), you can always
say it was never in high demand if it's brought up after the fact, and
nobody's going to be the wiser.  

Mind you, I'm just saying it -could- work to someone's advantage.
Regardless of the reasons, such a closed-system of a wishlist seems pretty
useless on the whole.  You can't get someone putting up 'x' idea, and
someone else seeing it and taking it to the next level, and so on until it
matures into its full potential.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html