Steve,

I agree that the complicated route isn't the one to take.

And I agree that programs would only check the flag on launch. But in the way I'm looking at this that's fine. If the flag gets set to false after shutting down a second screen reader and the first one is working fine I won't have to relaunch programs. And if I run the program to reset the flag after closing the second screen reader it will be true for any programs I launch thereafter. So the trick would be to run the program as soon as we shut down the second screen reader, which is what I would do because otherwise I'll forget. And after resetting the flag I can broadcast a system message that the flag was changed. So all those wild little party animal programs will be notified.

Regards,
Tom



On 11/8/2017 10:37 AM, Steve Jacobson via Talk wrote:
Tom,

Given my tendency to believe that the more complex something is, the more
likely it will cause problems, I think it might be useful to be able to
simply reset the screen reader flag upon demand as you suggest.  While I
don't see any flaws in your logic, I would caution that there could be
applications that only check the screen reader flag when they start.  In
other words, resetting the flag to true might not solve all problems.  One
would assume that the operating system would know the flag was reset, and
that might resolve most of the problems that would arise, though.  I have no
knowledge of how that flag is checked so this is all speculation which is
also dangerous.

Thanks for this information.

Best regards,

Steve Jacobson

-----Original Message-----
From: Talk
[mailto:talk-bounces+steve.jacobson=visi....@lists.window-eyes.com] On
Behalf Of Tom Kingston via Talk
Sent: Wednesday, November 08, 2017 8:52 AM
To: Olusegun -- Victory Associates LTD, Inc. via Talk
<talk@lists.window-eyes.com>
Cc: Tom Kingston <tom.kings...@charter.net>
Subject: Re: A little tech tip on Windows and screen readers.

Olusegun,

John is right. The program I wrote was just to confirm the problem. But
I read your message a while ago and have been pondering it while
luxuriating in Peet's coffee. That's my latest low-tech discovery.
Highly recommended. (smile)

WARNING! If you don't want to geek freak out close this message now!
Three ... two ... one ... lift off!

Solving the screen reader flag problem programmatically is possible, but
not very practical. A program that would take care of it automatically
would need to be loaded at startup, wait a little while, and check to
see if the flag is true. Then it would know your screen reader is
running. (No assumptions is the golden rule in programming.) If so it
would then have to begin a process loop. Here's what that loop would
have to do.
1. Enumerate all the running processes to see if a screen reader is
loaded. I might be able to query for Window-Eyes, NVDA, and JAWS
individually.
2. Get the screen reader flag status and see if it's false.
3. If both conditions are true then reset the flag to true.
4. Put the program to sleep for whatever time is determined to be
reasonable for how often the check is performed so it doesn't bog down
the system but doesn't wait too long before resetting the flag.
5. Iterate the loop and repeat the above steps. This is done
automatically but it is a process nonetheless.

Checking the flag is a simple function, but building a construct with
all running processes isn't exactly a small task. It's more or less a
slimmed down shell of the Windows task manager without a UI. So I gave
this idea a thumbs down.

Then a more practical approach came to mind. It would be a program you
could run to see if the screen reader flag is true and prompt you to
enable it if not. Yeah ... but, I thought, this really gets back to the
original solution of remembering to reload your screen reader because
you'd have to remember to run the program. But wait! I thought. It would
be beneficial because reloading our screen readers while some programs
are running requires us to close and reload the program due to the
preparations our screen reader does for that program when it loads. For
example, when I'm in my programming developer writing a program I cannot
reload NVDA. It cannot see the caret when I do so. It has to find it
when the program launches. And I've had to close and reload other
programs after reloading my screen reader because some things stop
working. Again, screen readers sometimes have to see the program launch
in order to work properly with them. Seeing the window come into focus
isn't always enough.

So, provided that our screen reader has recovered to a fully functional
state after having to load another screen reader to get there this would
eliminate the need to reload it to reset the screen reader flag.

Let me know if anyone sees any flaws in my logic.

Regards,
Tom

On 11/7/2017 10:19 PM, Olusegun -- Victory Associates LTD, Inc. via Talk
wrote:
Tom, I like the geeky nature of your post.  I thought you had mentioned
that
you wrote a program to solve the problem.  Is the program up for sale?  If
yes, how can I get it to snuggle up in my hands and at what cost?

Thanks for sharing and for making me a bit more geekier than I deserve!

Sincerely,
Olusegun
Denver, Colorado


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Ai Squared.

For membership options, visit
http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/tom.kingston%4
0charter.net.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/talk-window-eyes.com

_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.

For membership options, visit
http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/steve.jacobson
%40visi.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/talk-window-eyes.com


_______________________________________________
Any views or opinions presented in this email are solely those of the author 
and do not necessarily represent those of Ai Squared.

For membership options, visit 
http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/tom.kingston%40charter.net.
For subscription options, visit 
http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com
List archives can be found at 
http://lists.window-eyes.com/private.cgi/talk-window-eyes.com

_______________________________________________
Any views or opinions presented in this email are solely those of the author 
and do not necessarily represent those of Ai Squared.

For membership options, visit 
http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/archive%40mail-archive.com.
For subscription options, visit 
http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com
List archives can be found at 
http://lists.window-eyes.com/private.cgi/talk-window-eyes.com

Reply via email to