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/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
