Hi Bruce, What about switching to the WE cursor (Numpad minus); isn’t this the Window-Eyes screen browser?
Take care, Rod From: BX Sent: Wednesday, April 10, 2013 6:17 AM To: [email protected] Subject: Re: WEFramework - Feature requests Hi Rick, What I was thinking of is Windoweyes responds to data coming in. so, the displays are there, highlighted, but still there, and once loaded onto the screen then read them, not while there moving! This seems like a simple fix, using a browse mode with the cursor keys to read all of them, but browse mode only works for the web pages. But is this not what JAWS does all the time? In other words get a browse mode for the screen, just like the mouse, but storing the page as it develops and read everything, or selected colors, that would be useful and seems like very workable. Now Aaron, does not Windoweyes store all page activity as it is being displayed? The 2010 or probably 2012, all hints are in there own colors and such and seems like they would be easy to read along with all other screen data... For at the moment all Windoweyes does is go from control to control text field or where the focus is only; usually a text field... Something to think about and maybe even work on. Thanks Rick, I needed to explain what I meant a little better. Bruce Sent: Wednesday, April 10, 2013 3:29 AM Subject: Re: WEFramework - Feature requests Hi Kate and Bruce: Is it a problem of speech speed or of reading the window(s) before the window is fully formed with messages? I remember something about this and Aaron using a timer to wait for the events to finish. That is If I remember correctly since it has been some time now since I looked at scripting that puppy. I was going to get a new development machine with windows 8 but am waiting for now since I had to spend over a grand on a tooth - ouch! and WE with Windows 8 is still a little shaky from what I've been reading and VS is one of the more complex applications to try and work with for WE and for us to try and script. But try using a timer to delay reading if that is how Aaron did it back in the day... Rick USA ----- Original Message ----- From: BX To: [email protected] Sent: Monday, April 08, 2013 5:28 PM Subject: Re: WEFramework - Feature requests Hi Katherine! I thought that was the case. It would seem that Windoweyes has to slow down it's response time to VS 2010 or 2012 in order for any hints are placed on the screen and Windoweyes then can capture them. I just think it should be a simple fix, just a slower response time or another mechanism to do speech delay... Aaron is there going to be a fix? Bruce Sent: Monday, April 08, 2013 5:07 PM Subject: RE: WEFramework - Feature requests Guys, Im going to actually check on the VS 2012 intelisense; I keep forgetting that I normally use Vs 2012 with an alternative screen reader, and I sometimes forget that not everyone has that advantage. And Im sort of a VS junky anyway, so sometimes I suggest it without checking it out since it always works for me with either JAWS or System Access. But the lockup thingo should be fixed in the next update if Vs can work with other screen readers like JAWS and have no problems with the render of the intelisense. From: Aaron Smith [mailto:[email protected]] Sent: Monday, April 08, 2013 8:19 AM To: [email protected] Subject: Re: WEFramework - Feature requests These are good suggestions, David. I've added them to the wish list. Thanks, Aaron On 4/7/2013 6:37 PM, David wrote: I wonder, if a couple of features could have been implemented with the GW WEFramework app. First of all, every time I am to start out a new project, I will be going through the wizzard. This wizzard is nice, except from it keeping asking me info, that would be quite similar for every new project. For instance, my name, email and so forth, would be standard the same, no matter which project I am starting out. Would it be an idea, for the app to store these infos, in the ini file. Next time I start a new project, it then would suggest (or auto-fill-in the proper fields), this info in the wizzard. That would make the wizzard even more smooth and quick in usage. And, I could always change the info, should I for some reason want it to be different for a given project. That is, the app would automatically fill in the stored info in the proper fields, yet still show me the screens, that I could change whatever info I wanted. At least, it would save me from retyping the same info every new project. The other request I have, has to do with the final screen of the app. Here, you are offered to open the project file itself, or the XML file - in Notepad. Well, why not let the app do a quick test, checking if the UI Design app is currently running. That way, when I hit the Open button for the XML, it would be loaded directly into UI Design. If UI Design is not currently running on the computer and user, the XML could always be loaded into Notepad. But, long as the Design app is running, I really don't see the benefit of being offered from the Framework, to load the XML file into Notepad. Further, could there have been a way, for the Framework to offer to "Add On New Functionality" to an existing project. Recently, when updating the Extended Dictionary project of mine, I had to add on a new hotkey to the script. I thought I had made all the necessary changes, but happened to have overlooked one spot, causing the new hotkey not to work properly. If now, the Framework app had offered me a chance, of loading the existing project, and then adding a new hotkey, making all the necessary changes for me, that would have been saving me for some debugging. Likewise, when you start out a new project, the Framework does offer you the chance of including different features from the GWToolkit. But, what if you are not sure, when you start out with a project that later on will increase in functionality, which of the features you will eventually happen to need. Allright, the safest way, would of course be - as it stands today - to simply add on all the features listed. Then, they are all available for later usage. But that results in an exergerated huge script, and would maybe even pose a heavier load on the system, from what was really needed. Again, if I at a later state, could have let the framework add on the necessary lines for any new GWToolkit feature, to an existing project, that would have been really helpful. Hope all of this makes sense, and that it would be possible to have these updates to the Framework app, which really is a great tool for us, when developing new projects. -- Aaron Smith Web Development * App Development * Product Support SpecialistGW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825260-489-3671 * gwmicro.com To insure that you receive proper support, please include all pastcorrespondence (where applicable), and any relevant informationpertinent to your situation when submitting a problem report to the GWMicro Technical Support Team.
