CONTROL record maintenance Screens

[Deech Vogt]

What is the best way to design a screen to work on a single control record item in a CONTROL record file.

I've see this done two different ways:

1.) Using Work field definitions and then populating them using a BASIC subroutine in the After Read Rec process slot.  In After Screen Accept process slot another BASIC routine to collect the work variables and write them to the file.

2.) Using regular field definitions and using the Key Source (If Not Inp) with @PARMS(1)<1>:"!CONTROL.REC.NAME"  and SB normal screen reads and writes to display and update the record.

I think it should be done using the 2nd method.  I'm thinking the 1st method was used because of lack of SB+ knowledge.  Are the advantages to the first method?

Thanks,

Deech

[precisonline]

My personal opinion is to avoid complication whenever possible.  For this reason I would agree that #2 is the better way.  I've seen all levels of SB+ programmers find creative ways to include BASIC, simply under the assumption that there must be some BASIC somewhere, when really it's necessary only when it's necessary and a waste of effort otherwise.

The simplest approach here is a screen using ordinary field definitions just like any other screen, and if you don't want to prompt for the key, use the Key Source (if not Inp) as that's what it was designed to do.

So the only advantage I can see to the work field method would be the fulfillment of some masochistic fetish.  Otherwise, there's no reason to work that hard for a simple result.

[nmorgan]

Having looked at a lot of the code in Prelude over the last dozen years, I'd agree that they seem to have a penchant for "doing it the hard way".