Hi Guys: OK, after having turned off the mouse voice setting the phantom speech went away. But, now when in some lists like the "This Computer" list of drives and reviewing the Context Menuu or in my own program WindowEyes will sometimes start reading a list item then stop, speech is cut off before the end of the list item with focus. Also, in the list sometimes I hear 2 items read after hitting the down arrow key instead of just one. Also, some list items are not read at all unless I ReRead the list several times - it seems they are there sometimes and not there other times. So I turned the mouse voice back on. I went into the "This Computer" and the Context Menu items read very well except for a phantom word "graphic" reading on the first item indicating again that the WindowEyes use of the mouse related to dynamic content is likely causing problems. This is not good since if I turn it off I don't get phantom speech but it seems I have even more serious problems, sigh. The real situation here seems to lie with the underlying mechanism WindowEyes is using to monitor dynamic content and execute speech. I am not sure there is anything a end user like me can do to improve or work-around these what appear to be fundemental WindowEyes buggs since they may lie in the design of their code rather than just being a simple bugg. Also, just thinking, allot of the dynamic stuff is handled by using a delay before speeking something to ensure it is fully displayed before reading it. Here is something I thought of: A control starts to read, another dynamic feature happens and WindowEyes chopps off the speech or doesn't speak it as the second read happens and is trying to read either before the wait time is up on the first read or in the middle of reading it thus chopping it off - now, there is no way of checking something like this out since multiple main code and multiple scripts are all handling dynamic and focus changes at the same time which makes trying to analyze these types of problems impossible from my view of the WindowEyes platform. If my test are accurate, and they well may not be since everything is so dynamic and the problems so many and so intermittant, there are fundemental design flaws in the WindowEyes platform that need to be ironed out or WindowEyes will remain very unstable and the symptoms may seem so diferent from test to test that trying to nail down the problem will be close to impossible. The current and past tests are indicative of how fixing one problem will cause another problem with the current design if my analysis is correct and, again don't get mad, it may be incorrect since I can only see symptoms and not the entire code base to try and debug the code base. Even if I were a programmer with access to it trying to figure out if the problem was in the underlying code base, could be in several places if messages are processed on demand, or in one of several scripts conflicting with each other due to timing as mentioned above or other problems related to how WindowEyes handles dynamic content changes while trying to handle visible focus changes with the standard tab and arrow keys. There are some good WindowEyes folks on this list and the scripting list so if all this gives you any ideas perhaps you could suggest something or work with AI2 to help them fix WindowEyes so it is more stable. I don't have the time nor WindowEyes experience to handle such a project. But, if the AI2 guys are still reading this list they may benefit from this thread and consider their options. Rick USA
_______________________________________________ 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
