Vocal-Eyes for DOS (the model to adapt for clipboard capabilities, in my
opinion) is limited to text displayed on the screen. It can be anywere on
the screen and a block can be as many lines as desired (by marking the upper
right and lower left corner). One can append subsequent blocks to the
clipboard buffer or replace it with the new strings. One can determine the
separation character that Vocal-Eyes inserts between appended strings.
For example, there is an online service called Legi-Slate that I use
extensively at work. I run a search of certain keywords I'm looking for in
legislation, regulations, or Washington Post articles. The report (which I
capture to disk) gives titles of articles and code numbers in its database.
I read through the output file and append the article code numbers to the
Vocal-Eyes clipboard using a space as the separation character. I can then
do a download of all the articles I want with a single command line that
includes the list of article numbers. Other types of articles require a
comma rather than a space as a separation character between codes (I
don't know why this inconsistency exists in Legi-Slate). AIn other
applications, I indicate that a carriage return should be the separation
character before pasting a series of blocks I stored to the clipboard.
With that said, a Windows adaptation of a screen reader clipboard
could be more powerful than the Vocal-Eyes one by allowing other parts of
the off screen model to be copied and pasted, even if they are not
visibly displayed on the screen. I would
see that as a future enhancement, not needed in the basic implementation.
Regards,
Jamal
On 1999-01-12 [EMAIL PROTECTED] said:
NJamal, in the Window eyes implementation, are they restricted to
Ntext that is on-screen?
N-
NVisit the jfw ml web page: http://yoyo.cc.monash.edu.au/~nallan/jfw
Net-Tamer V 1.11.2 - Registered
-
Visit the jfw ml web page: http://yoyo.cc.monash.edu.au/~nallan/jfw
