What should fp 6.0 look like?

[tom heine]

how about some basic stuff?

search and replace in rcabe!!!!

an "undo" feature in rcabe  - like control z in ms word.

a warning when you go into a process table if its already open.

More Index's per file   (this is huge)

associated fields working in dual criteria index's

tom


----- Original Message ----- 
From: "Jay R. Ashworth" <jra at baylink.com>
To: <filepro-list at lists.celestial.com>
Sent: Friday, October 22, 2004 11:31 AM
Subject: Re: What should fp 6.0 look like?


> On Thu, Oct 21, 2004 at 04:55:39PM -0400, Walter Vaughan wrote:
> > Kenneth Brody wrote:
> > > I have a POP3 client written in filePro 6.0, if that helps.  ;-)
> > 
> > Smiley duly noted. However it does bring to mind what kind of features 
> > are needed for a filePro 6.0. Realistically, what else's needed?
> 
> Hmmmm...
> 
> (Yes, I am still alive.  Though, alas, my mom isn't.  :-{)
> 
> > One of the huge issues/problems with memos were the inability to print 
> > them on reports. Well that's been fixed in 5.0.14.
> 
> If it works for you.  :-)
> 
> > So. What's needed in a 5.1 or 6.0? I mean, what features that could be 
> > added to 5.0.14 that are currently not being met that would cause 
> > developers to purchase and encourage their customers to upgrade in 
> > significant percentages?
> 
> Reliably solid error messages that always reflect what actually broke?
> 
> > It's not like filePro is unstable. 99% of sites today could last fine 
> > until 2028 and the hardware gives out or the last of the developers give 
> > out and start pushing up daisies.
> 
> 2038, when the time_t's wrap around.  :-)
> 
> > filePro's original power was it's ability to create applications 
> > rapidly. To remain "current" we've had to do a lot of low level stuff 
> > that should be done with a single filePro verb.
> 
> There's a balance you need to strike.
> 
> You need highlevel verbs to do common things, with good defaults, but
> you need the available low-level knobs to make it possiblt to do
> off-the-beaten-path stuff without having to reimplement something that
> is there, but not flexible enough.  
> 
> Like browse lookups, and all the knobs they've grown over the years.
> 
> But, AFAIC, the number one item that needs to happen or you shouldn't
> even be calling it "6" (the current version is, if you apply what there
> is of an industry standard to version numbering, about 3.4 or so :-) is
> header/detail handling that you don't have to write yourself.
> 
> This could be done as merely an "active" or "Editable" browse lookup,
> if there isn't any obvious way to do it directly on the screen; as long
> as the indexing and locking could be handled correctly, that would be
> enough.
> 
> Cause, y'know, over reimplementing that myself.
> 
> > One of the things that keeps poping up on this list is import/export 
> > issues. A full suite of import and export tools. Working with Xbase 
> > files, Excel files, MDB tables, XML files. Not via OBDC, but as an 
> > external file. Keep It Simple, make it easy to use.
> 
> Two Words: Commercial Opportunity.
> 
> > I know it sounds like heresy to think that anyone would want to export 
> > data from filePro to be used in an other application. Heck, not only 
> > have the animals gotten out of the fence, but they've paved over the 
> > corral, everyone's moved to the suburbs, and five guys in sunglasses are 
> > running around doing a complete makeover on a worn out brownstone where 
> > the gate once was.
> 
> :-)
> 
> > I'd like a professional IDE. Not character based. We gotta kill the 
> > Tandy DT-100 mentality.
> 
> So saith you.  Greenscreens are your friend, dude.  Really.  Good GUI
> useful *too*, but I can't run a GUI app from my Blackberry.
> 
> >                          Color coded with building block icons. Heck it 
> > could/should be web based written in JAVA. End users don't specify 
> > filePro. Developers build in filePro because we used to be able to 
> > deliver state of the art applications quickly. That racetrack now is a 
> > apartment complex with a 24 hour mall and a riverboat casino.
> > I should be able to drag an export icon to the processing table and it 
> > should ask me what I want, and tell me if I made a mistake, and show me 
> > an example of what my choices would look like. If I wasn't so lazy in 
> > the first place I'd of written apps in 1987 in assembly like I used to 
> > do on my Commodore 64.
> 
> Fine.  So we need both.
> 
> Two words: commercial opportunity.
> 
> If the backend with the text screens and the programming language is
> *architected correctly*, you can drop all that stuff on top.
> 
> > Kill processing table line length limits.
> 
> Yeah.
> 
> > Kill report width limits.
> 
> Whoa, yeah.  As well, as Mark notes, as screen size limits.  Why
> *can't* I scrool?
> 
> > LOCKEDBY(file) array to return @id of lock-er
> 
> And, Ken's arguments notwithstanding, there *has* to be a way to
> engineer this.  Perhaps it will take another lock table for the clients
> (which surely know who's running them) to store it in.  So be it.
> 
> > Well that's enough ranting.
> 
> Not *near* enough.  :-)
> 
> 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
> 
> "You know: I'm a fan of photosynthesis as much as the next guy,
> but if God merely wanted us to smell the flowers, he wouldn't 
> have invented a 3GHz microprocessor and a 3D graphics board."
> -- Luke Girardi
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>