Re: More than 99 indicators needed

[Tom Liotta <qsrvbas@xxxxxxxxxxxx>]

Charles Wilt wrote:
> On Wed, Oct 15, 2008 at 4:51 PM, Tom Liotta <qsrvbas@xxxxxxxxxxxx> wrote:
> > > I also hate to mention this, but if you always used pairs of indicators
> > > in that file, you could mentally consider the indicator indexes to be 4
> > > digit numbers, 0113, 0275.  Then you could use a procedure to actually
> > > set the individual indicators.
> > >    setInd (0275 : *off)
> > > would split the number into two 2-digit numbers and do
> > >    *in(02) = *off
> > >    *in(75) = *off
> > That seems (at first glance) to be simple. But what happens to the
> > field on the same line that has *in(02) *in(76) and needs to be *ON?
>
> That should be ok, the line with 0275 would be *ON,*OFF which since
> we're AND'ing has the same results as *OFF,*OFF

Then why have two indicators? There are only two practical values -- 
*ON/*ON and everything else. The values *ON/*OFF, *OFF/*ON and 
*OFF/*OFF all work out to a *OFF result.

The 1st *in() effectively declares a "group" of indicators. But for 
any given print-line, it can have only one value. As such, each 2nd 
*in() must still be separately set. Further, the 2nd *in() can't be 
used to control a different field in another "group" on the same 
print-line unless the other field (or every field in the other 
"group") has the same HIGHLIGHT value setting.

When the value of the 2nd *in() is *OFF, the ANDed result will be 
*OFF regardless of the 1st. And turning the 1st *in() *ON will have 
no separate effect unless the 2nd is also *ON.

And when the 1st *in() needs to be *ON, a proc call like:
 [ setInd (0276 : *off) ]
would really be tricky if
 [ setInd (0275 : *on) ]
had just been completed.

I guess that the point I'm making is that _any_ subsequent developer 
better be very clear on what is going on with this.

Tom Liotta