Carla.Campbell@f89.n129.z1.fidonet.org (Carla Campbell) (04/05/91)
Index Number: 14639
[This is from the Blink Talk Conference]
CH> but, I can go into review mode and the machine keeps moving
CH> along, no problems.
OK, here's where I might be able to get an explanation of something I have
wondered for a long time! Please enlighten me...
I have always used programs with review modes which halted processing.
Once in a while (say, during a transfer, if I go to look at the "elapsed
time" and take too long, etc) this has been a problem. More often than
not, however, I have found it to be a "useful feature".
When I run a directory (not that I do often with SDIR around, but once in a
while I do) or do a type command, and I hear something I want to look at
more closely, all I need to do is pop into review mode and go look. When I
am done and exit review mode, the listing just continues where I left off.
Similarly, online, I sometimes use review mode instead of ctrl-q/ctrl-s to
stop and startincoming data. All I have to do when I am done reviewing the
screen is exit review mode, and the data which has been waiting comes right
on through-- I don't miss a thing. (unlike when I use ctrl-q/ctrl-s, when I
do miss a little bit of the text fairly regularly) I don't have to
remember to pipe things through the DOS more command or use /p when running
a DIr. I have what ammounts to a verbal scroll-lock.
A while back, I tried Vocal-Eyes (an older demo, but I liked what I saw,
nonetheless). The most awkward thing I found while using it was the review
mode that didn't stop the computer! I know that sounds silly... but has
anyone else here encountered this "problem"? If so.. how do you get around
it? Do you just have to alias "dir" to "dir /p" and so forth? Do you just
have to do the extra keystrokes to stop and start data when online? How do
you handle those programs where you have to go into review to read
something, but also need to know information that's about to come onto the
screen?
Trust me to be weird, but I just didn't find the 'non-intrusive' review
mode to be more of an advantage than the 'obtrusive' type are an
_advantage_. So.. shoot me. <grin> Failing that, tell me how to "get
around" this nice feature!
--Carla
... Read what I mean, not what I write!
--
Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!129!89!Carla.Campbell
Internet: Carla.Campbell@f89.n129.z1.fidonet.orgRay.Campbell@f778.n115.z1.fidonet.org (Ray Campbell) (04/11/91)
Index Number: 14685
[This is from the Blink Talk Conference]
I have used Vert Plus for about 5 years now. I like the fact I can go
into Review Mode and look at something, then exit review mode and keep
getting data coming onto the screen. I don't even used ctrl-q/ctrl-s at
all. I have seen programs (i. e. Jaws, VP) where the computer doesn't
stop when you go to review something. I agree with you, Carla, that
having this "scroll lock" is nice.
--
Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!115!778!Ray.Campbell
Internet: Ray.Campbell@f778.n115.z1.fidonet.orgAl.Hoffman@p0.f143.n109.z1.fidonet.org (Al Hoffman) (04/11/91)
Index Number: 14687
[This is from the Blink Talk Conference]
Here are some examples where I can compare ARtic "halt review," with
Ibm(s) "pointer," mode.
When using a 3278 terminal emulator on the IBM mainframe at work,
there is a job input, output, and hold reviewing system, it looks like
this:
ispf held output listing 18000 lines
====>
id# job# class lns prt etc.
xh230 2048 x 2050
xhp78 2052 x 8590
------------------------------------------------------------
So: your cursor is on the line with the ====> and if you hit
return your screen is updated. Of course this is all direct screen
writes, so no easy way out. With the halted review mode, you are in
trouble, although with the use of tags, you can make ARtic do a
non-intrusive review mode.
Basically you want to do several things with this screen, hit
return, look for your job status changes, such as if lines printed went
down, and so on, but you don't want to go into review, find the line,
and then read it, with a nonintrusive, you can leave your pointer mode
on the line, and just read after a return each time, or even make the
program watch the line you define.
Anyway, another example:
With Telix, or Procomm, and ARtic, I have noticed a easy way to
mess up a file transfer with zmodem, just go into review, and for that
matter, you can even mess it up by just hitting the review-line key too
many times. It doesn't seem to interrupt very well, and neither did the
SoftVert test I tried.
I am not trying to be critical just making observations.
OK, next example of where pointer modes are OK, is the dir example
you gave.
dir *.xxx (whatever you please /p will pause the screen with no
mess, no fuss. You can then wonder around in pointer mode to your
hearts desire, and, stay at the top if you like and hit a key to
continue--and then read the next screen from top to bottom. Sort of
like, you dir/p then read up, hit a key, and read down ...
I have a setup for artic with a key macro program using tags that
lets me use alt y and alt t, to move up and down, reading, in a
non-intrusive review mode. Basically you just set a tag, and read it,
then when the next loop or time through, tag = tag + or - 1 depending on
the up or down key you hit. This works fairly well, but you can't make
it truely silent.
Another thing is during transfers I leave my pointer at the size,
and just hit read word once every once in a while, can't do that easily
with any pointer system I have had, including Artic 2.x, Screen Talk
v2.x, SoftVert v4.something, Verbal Operating System v something new (my
roomates machine).
It can be handy to have the ability to halt things before they get
out of hand, but you relearn things as you go, and learn to easily live
with out it, heck, with Screen Reader you could probablly make the PAL
language make a machine halt if you wanted, I'll try that, ssome BIOS
call or something. Hmmm.
Well, I hope this msg have given you a few ideas, send me more,
I'll keep thinking with you.
--
Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!109!143.0!Al.Hoffman
Internet: Al.Hoffman@p0.f143.n109.z1.fidonet.orgCarla.Campbell@f89.n129.z1.fidonet.org (Carla Campbell) (04/11/91)
Index Number: 14722
[This is from the Blink Talk Conference]
AH> Here are some examples where I can compare ARtic "halt review,"
AH> with Ibm(s) "pointer," mode.
Thanks, Al-- your thoughts were just what I was looking for. I have long
seen the advantages of _having_ a "pointer mode"-- though you bring up
some ways of using it and advantages which I had not considered.
My "ideal world speech program" (Hereafter, MIWSP for short. <grin>) would
have both capabilities: allowing processing to continue or to obtrusively
stop the world while I get off and look around a minute. <grin>
While, as you say, a Dir or a type or any other command can be run with
a /p or ">more" command, I'm lazy. I'm too lazy to have aliased the
commands "dir" and "type" to "dir /p" and "type >more", much less to
type them. (assuming that I used Dir and Type: in fact, I usually use
SDir and Sqwint, but that's another story. I used Dir and Type as
examples because they are more familiar than other utilities which I had
in mind.) But that's trivial. If it bugged me enough, I'd alias it. My
laziness _does_ have a threshhold, at least, beyond which I do myself a
favor and fix things. <grin>
The more usual use I have for halting processing is online. I do
extensive work on systems with live conferencing capabilities. I use an
external modem with a Tweedle-Dump on the cable (incidentally, I have
had no trouble with this gadget and have found it to be very useful). I
sometimes have to do other things while I wait for the system to do
something or while I wait around for other users to appear and say
something. What I do is to go into review mode. Then, I hear
information coming in by the Tweedle-Dump's buzzing and can go get out
of review and hear anything which came in whilst I was away from the
keyboard. Since this is not like downloading, I have never had
buffering problems with incoming data. If I used ctrl-s, ctrl-q, I
would not know that anything had happened, since nothing would have come
into my modem or come across my screen. If I simply turned off speech, I
would have to go into review/activate the pointer and move around the
screen, perhaps even having to <gasp> scroll back a screen or two to
catch everything when I ran over to turn it on again on hearing someting
coming in
The "Scroll-back, review and scrounge for new information" technique is
slow with speech. I must be _fast_ with this work-- and am. Many people
have no idea that I use speech synthesis. (While I do not _care_ who knows,
I don't always like to spend my whole evening talking about talking
computers and would rather just do a fast, efficient job of what I do and
deal with the other matters at hand. I talk about speech synthesis plenty
at my real job and here on the echo. <grin>)
I know the above is a very unusual situation, but MIWSP would deal with it,
somehow. In the meantime, since no one is leaping forward to write MIWSP,
I wonder if you've got any brilliant ideas of a good work-around, were I to
be using a program with a 'non-intrusive review mode" or "pointer". You've
got great ideas about using the pointer, so I figure you're gonna have
something for me on this, too! Right?
The more common use I have for the "system halting" review mode is just to
catch the opening screen of a program, without missing the next data which
passes across the screen, or to stop at log-on to a system to catch the
bulletin info a second time. (this could be accomplished through a series
of maneuvers of scroll-back and review mode, but again, I'm lazy.) I use
it to catch messages which are flashed up on the screen oh-so-briefly,
again, without losing the next data to be displayed. That sort of thing--
situations in which the program or utility has no way of pausing output are
particularly of concern to me in this discussion.
I cannot think of any way, save for your suggestion of yet another TSR
(or internal script, in the case of Screen Reader) to run to "pause" the
computer's processing. I would accept such as a viable solution if it
were truly a well-behaved program which worked properly from inside
other applications and did not interfere with other TSRs such as my
speech software-- or, as per your suggestion, if it were simply a
scripted extention of the speech program, itself.
AH> Basically you want to do several things with this screen,
AH> hit return, look for your job status changes, such as if lines
AH> printed went down, and so on, but you don't want to go into
AH> review, find the line, and then read it, with a nonintrusive,
AH> you can leave your pointer mode on the line, and just read
AH> after a return each time, or even make the program watch the
AH> line you define.
I can definitely see the use, here. To achieve the same goal, I would
do one of two things. If that screen was the one I was going to be
using all the time, I would, as you suggested, set a monitor (or
hyperactive or wahtever we're calling them this week) window to look for
changes and read them aloud when they're spotted. that way there's no
key-press at all-- not even a move to pointer and read current word one.
If, instead, the screen locations in which I was interested changed, I
would go into review and use the "go back to last location" command or the
"go to previously marked location" command and read the current word.
(Willie, you wanted to know where people used macros-- this would be an
example of a good place to use one!). That is more keystrokes than a
pointer mode would use, and I admit I don't like it, either. Just
describing how it might be dealt with, application willing. I prefer the
monitoring option.
AH> With Telix, or Procomm, and ARtic, I have noticed a easy
AH> way to mess up a file transfer with zmodem, just go into
AH> review, and for that matter, you can even mess it up by just
AH> hitting the review-line key too many times.
For that, I have defined a window that is very small-- the exact size of
the area saying what is left to download-- elapsed time and bytes
received-- I read the window with an alt-whatever and it does not seem
to bog down the transfer. Dunno what it would do at 9600, but it's ok at
2400. I use it infrequently during any given transfer, but have found no
problems with doing it that way-- unlike, as you describe, doing it the
review mode way.
I am not for a moment suggesting that my laziness ought to be catered to
over someone's ability to use programs such as the 3278 emulator
situation you described with ease... just wondering if ya can't,
somehow, have your cake and eat it, too. <grin>
I enjoy the different perspectives and ideas of work-arounds for
speech-awkward situations that this sort of discussion uncovers. Thank
you for taking the time to give me your thoughts on the matter! I am, if
I was not before, convinced that pointers are useful critters-- now I'm
just looking for time-efficient work-around ways of dealing with the
things which I use review mode for before I start _wanting_ a pointer of
my very own. <grin>
Talk at ya soon.
Cheers.
--Carla
... Read what I mean, not what I write!
--
Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!129!89!Carla.Campbell
Internet: Carla.Campbell@f89.n129.z1.fidonet.org