Header detail coding in filePro (was Re: Using filePro - Was Associated Fields and @AF)

[Jay R. Ashworth]

[ FYI, Nancy: for some reason, your mail client sent *two* separate
replies to this, one to the list and one to me, instead of the common
one copy, sent to both addresses.  This can be troublesome since the
direct copy often arrives first, and the recipient thinks that the
message has been taken off-list, with the expected results.  You might
look for a knob that changes this behavior... --j ]

On Tue, Jul 05, 2005 at 09:32:36AM -0400, Nancy Palmquist wrote:
> Jay R. Ashworth wrote:
> > On Fri, Jul 01, 2005 at 09:37:50AM -0400, Nancy Palmquist wrote:
> > 
> >>I write filePro applications.  I have for over 20 years (as long as 
> >>there has been filePro).  I do it for a living, full time.
> >>
> >>I have designed many,many applications over the years and I have yet to 
> >>see any other database that can offer the same flexibility, and ease of 
> >>development.
> > 
> > So, given that, Nancy -- and I'm not rousing rabble, here; I really
> > wanna know:
> > 
> > what percentage of those apps have necessitated header-detail U/I, and
> > how did you deal with it? Your own toolkit? Someone elses? Write it from
> > scratch every time? Fake it? Or redesign to avoid it, at the cost of
> > trainability?
> 
> Many of the apps have header/detail file structures.  Not all require
> it.  Once I learned how to do it, it is not hard to do.  I have
> developed a style that works for me and just repeat with the variations
> required.

"Built my own toolkit."  Ok; that's sort of what I expected.  So did I.

> I have found that using old code for that part of the programming
> (header/detail) is not effective.  The reason is that each application
> is unique and I find that modifing existing code is slower than starting
> from scratch.

"Build it from scratch every time"?  Hmmm...

> I do have many toolkit chunks that provide logic for listbox selections,
> printer selections, scan/select tables, writing exports, creating menus
> and stuff like that.  I use those when I can to save time.

Ah.  Got it now.

> I have seen many styles and solutions to the header/detail logic.  I
> prefer having a common start place, like the customer record or an order
> record.  Then make everything happen from there.  I just add @key logic
> for each new function.

Yep.

> I is just such a central part of developing an application that I would
> find it difficult not to set it up that way.  In my experience, if the
> customer gives a limit to detail lines of any kind, they are always
> wrong and will need more later.  So the design that allows 5 detail
> lines on the invoice record using associated fields, like the tutorial
> will fail because they will want more lines very soon and in the long
> run it makes reports more difficult to create based on the detail.  Just
> adding the extra programming for a header/detail design will save much
> work on report and output design later, the real point of collecting the
> data in the first place.

Perfectly correct.

> I should put together a class for my web training on designing a
> header/detail structure and how it is done.  Maybe some out there would
> be interested.  I could easily do it, it is a class I have done live in
> the past.
> 
> Well, I can see it would require more work for a developer that does not
> do this for a living or is learning as they go.  It does not require
> very difficult filePro logic, just a little code.  Basic tools require,
> BROWSE, arrays, dummy fields, popup update and such.

Yep.  I think my implementation ran about 300-400 lines of
non-application-specific code; I have to dig it out again.

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

      If you can read this... thank a system administrator.  Or two.  --me