Re: SFL More

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 08/01/2017
03:01:55 PM:

----- Message from Dan <dan27649@xxxxxxxxx> on Tue, 1 Aug 2017 14:
22:54 -0400 -----

To:

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

Subject:

Re: SFL More

On Tue, Aug 1, 2017 at 12:30 PM, Booth Martin <booth@xxxxxxxxxxxx>

wrote:

This re-raises a question for which I have never seen a reasonable
answer. The whole computer world uses and understands scroll bars.

DOS,

Windows, OS/2, HTML, JAVA, javascript, iOS, androids, Everything

else.

Except 5250 shops. We've had scroll bars available to us for...

gosh... 25

years? Yet we pooh-pooh them and refuse to use them. We will do

everything

imaginable to create the functionality, but we aggressively refuse to

even

consider a very simply implemented scroll bar.

Why do we avoid scroll bars? Scroll bars allow scrolling, they allow
inching. They show our place is the subfile, and they provide an
indication as to the size of the subfile. All by just by adding 7
characters. There is nothing else to do. Nothing else at all.
Constraints needed are 3 empty columns and using the actual subfile

size

for the SFLSIZE keyword. Yet good, experienced RPG programmers raise

their

hackles and get red in the face when scroll bars get mentioned.

Booth, in my limited experience and from old memory, the problem with

5250

scroll bars is, when you use them on subfiles that are built a page at a
time, the scroll bar doesn't represent how much data is in the subfile.

I

remember users being annoyed that the scroll bar kept getting smaller as
you paged down (because more records were being added to the subfile),

and

they felt "fooled", never really knowing how close to the end of the
subfile they were. Also, some subfile programs never exceed one page of
subfile records; a page up or page down will clear the subfile and new
records written to that.

Now, if all of your subfile programs always fill the subfile before
displaying it, then I agree that scroll bars can be useful. But, I

would

never willingly write a program that does that.

A simple SQL statement returning COUNT(*) gives you the number of records
and the SFLSIZ keyword can use a program-to-system field to set this.
Using these simple techniques yields a workable scroll bar.

Also, those 3 columns removed for scroll bars are oftentimes valuable.

Agreed. Although most of the time there's a field which can be truncated.
I've never used the scroll bar in the past, but with Booth's post I did
some quick checking and revised a subfile program. It wasn't hard. In this
case the last field was a long format name. I checked for length greater
than the newly shortened length and swapped the last 3 characters with
"...", e.g., "Jonathan Hempleburt Smithson" became "Jonathan Hempleburt
Smit..."

Why do we avoid scroll bars? When users see a scrollable screen with

out

a scroll bar their first reaction is "This is ancient" and they are

right.

We are doing this to ourselves. The training curve is zero. The

result is

an attractive window understood by everyone.

. . .
. . .
. . .

No one using a 5250 screen with them is going to say "Ooooh, modern

GUI!"

If one is concerned about the perception that a 5250 screen generates,

they

should be moving towards the browser interface and forget about 5250 eye
candy.

- Dan

Again, you're point is very valid. But in cases such as the OP presented,
the scroll bar could be a viable option.

Of course, I type this up and do some testing because it's fun and now I
found some very odd behavior after I hit the actual bottom of the subfile
(and EOF of the source file). If I used the scroll bar to move back up in
the subfile, anytime I hit Page Down, control was returned to my program
rather than simply paging down within the already loaded subfile. In this
program, it displayed a message that the bottom of the data (aka subfile)
was already displayed. That's a real problem. More investigation would be
needed so I don't think this change will move to production anytime soon.
I've got real work to do.

Michael Quigley
Computer Services
The Way International
www.TheWay.org