RE: Re[2]: "extract" command enhancement (subfiles and BIFs)

["Dan Bale" <dbale@xxxxxxxxxxx>]

David,

>SFLSIZ>SFLPAG simplifies scrolling, it's efficient because it avoids having
>constantly to re-read database records and it simplifies the processing of
>pending options - with the single exception I mentioned.

Actually, two exceptions: 1) the "position to" and 2) the "page up" from the top
of a postioned-to subfile.  I'd disagree that it really simplifies scrolling;
the code's already in the program to add the next page of subfile records, just
clear the subfile before adding.  But that would be nitpicking. <g>

>In practice it's relatively rare for a user to "position to", make
>selections, then roll down. It does happen, but not often. I've never had a
>user complain about lost options or even report the bug. But I know it's
>there and I don't like it. As I said before BRMS has this bug and I've never
>seen anyone else refer to it.

I would argue that users learn the limitations of a particular application, then
work within the limits, as long as it doesn't impact their work.  This is
especially true for shops with backlogged programming requests.  "You've got a
workaround.  Use it until we can get to it."  And then, they never do.

>User indexes are one of several possible workarounds for the bug, but I
>would consider their use in this context a clear violation of the KISS
>principle.

How about if it were "wrapped" into a procedure?  (Again, this is/will be
discussed in Gary Guthrie's article.)  Otherwise, I'd agree.

>I think this whole debate confirms that while subfiles are great, they're
>not as easy to program for as they should be.

Agreed.

- Dan Bale





+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---