Eric.Bohlman@p1.f778.n115.z1.fidonet.org (Eric Bohlman) (09/13/90)
Index Number: 10255
[This is from the Blink Talk Conference]
There are two places where a speech program can find the cursor location. The
first is a few locations in low memory maintained by the BIOS. Whenever a
BIOS function is used to move the cursor, these locations are updated. A lot
of software that writes directly to the screen still uses the BIOS functions
to move the cursor and do scrolling, so those locations are usually up to date.
The second place is a couple of registers on the CRT controller chip. These
are what actually determine which character on the screen is going to have a
blinking line under it. The BIOS routines update these registers, and some
software writes to them directly.
With all that said, there are some programs where neither location will tell
you where you are on the screen. For example, it's perfectly possible to have
a lightbar moving all over the screen with the cursor constantly parked in one
corner. The screen is just an array of characters and attributes, and can be
accessed directly without affecting the cursor. This sort of thing is
becoming more and more common. That's why Tinytalk has lightbar-detection
windows as well as a lightbar-reading option associated with cursor tracking.
The latter depends on the cursor moving with the lightbar (but doesn't slow
the system down); the former continuously monitors a section of the screen for
attribute changes. This is more general, but on a slow machine it can eat up
a lot of processor time.
--
Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!115!778.1!Eric.Bohlman
Internet: Eric.Bohlman@p1.f778.n115.z1.fidonet.orgNancy.Feldman@f605.n105.z1.fidonet.org (Nancy Feldman) (04/25/91)
Index Number: 15197
[This is from the Blink Talk Conference]
OK, I have noticed an odd thig while tracking the cursor in some
programs, and I am wondering if there is a cure for it or not. Or
even what causes it?
First of all, most programs I use that require cursor control write
directly to screen. So when I need to find out what prompt I am at
or what response a specific action gave I have to toggle into
screen review mode to lok at the screen.
OK, so say I have a menu that says something like:
Global
Mailer
Files
Modem
Printer
Exit
Now I look at the screen in review mode and read the current line
and it says:
Global
I want to modify the Modem initialization strings, so I need to get
to Modem. It is 3 below Global so I hit Down 3 times and then,
though I don't always do this, I decide to make sure of where I am
now. So I toggle back into screen review mode and read the current
line.
Now here is where the problem arises. Most programs will tell me
that the current line is
Modem
or whatever I have moved to. But some won't. They will always say
Global
no matter how many times I use the arrow keys, even though I know I
have moved. I know because I hit return and a new menu or prompt
comes up.
Now, what would cause this? What is the difference between the two
types of programs? Does anyone know?
I ask because programs that don't read the exact cursor position
when in screen review mode (for whatever reason) can occasionally
be difficult to use. If I lose track of my position I may not
always want to just hit return to find out where I am. This could
have interesting results if that option actually runs a program,
say something like compiling the nodelist.
Please note that all of the above is just an example. No such menu
exists that I have used, I was just writing a quick menu for use in
this problem description.
You know the main reason that menu couldn't exist. It isn't
written for sighted people. No fancy graphics or anything. <Grin>
-> MegaMail v2.01 #0:It sounds too good! What's the catch?
--
Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!105!605!Nancy.Feldman
Internet: Nancy.Feldman@f605.n105.z1.fidonet.org