TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Scroll size, take II From:Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA> Date:Fri, 14 May 1999 14:22:03 -0400
Kathy Ellis continued the discussion: <<The algorithm is
exactly what I'm looking for!!! Does anyone know what it
is?>>
This suggested a call to my local programmer guru (thanks,
Jan!), who proposed the thought that the scroll bar moves the
image one screen at a time, but leaves a bit of the image from
the previous screen for overlap: that is, if your screen holds
10 lines of text, it moves you down to show the last of the 10
lines at the top of the screen, plus another 9 lines (for a total
of 10). Graphics apps would behave similarly. Since I'm a
recovering scientist ("...but I'm feeling much better now."), I
tested this, and it's true for the three applications currently
open on my Windows system.
So there you have your answer: the scroll bar moves you one
_screen_ at a time, and the arrow key moves you a distance
that depends on the nature of the application. (In fact, it's
programmable. You can see that the amount differs by
selecting a line of 12-point text in Word and changing the
point size to 72 points; hitting the down arrow key or clicking
the down arrow on the elevator bar moves the cursor to the
bottom of the line of 72-point text, not midway through it.
<<The programmer didn't know and just passed it off as
Microsoft's invention, but that doesn't help me at all.>>
The programmer was being lazy, since this information
should be clearly presented in the programmer's API guide,
the functional specs doc, or both.