Yes Rick, the OnKeyDown and OnKeyUp give you lots of control, while the OnKeyProcessed variations only let your app know when the key has happened.
good luck, Chip > -----Original Message----- > From: RicksPlace [mailto:[email protected]] > Sent: Sunday, June 10, 2012 5:13 PM > To: [email protected] > Subject: Re: A VBS and Wrappers Question > > Hi Chip: I will try the OnKeyDown and, or, the OnKeyUp and > set the disposition to see if that handles things. > Thanks again, I thought the OnKeyProcessedUp and down would > have done this. > But, I will try the OnKeyUp and down since it sounds like I > can then control what is passed through to vb.net 2010 > express via the disposition. > Later and have a nice Sundy evening. > Rick USA > ----- Original Message ----- > From: "Chip Orange" <[email protected]> > To: <[email protected]> > Sent: Sunday, June 10, 2012 2:35 PM > Subject: RE: A VBS and Wrappers Question > > > > Rick, > > > > Sorry but I didn't follow any of that; especially when you > brought up > > the "key process event" while speaking of things to do with > the VS IDE. > > > > Anyway, if what you need is to keep a keystroke from > reaching VS, then > > follow the instructions for registering a cursor key, except you > > register a hotkey instead. This lets your app know about the > > keystroke, but not VS and not WE. > > > > Finally, if what you need is for VS to see a keystroke and act upon > > it, but you don't want WE to see it because WE is speaking > something > > incorrect, then this does get tricky. The onKey event of > the keyboard > > object will let you keep WE from seeing a key, while > allowing VS and > > your app to know about it. > > > > The last thing I've hard on this topic, which I thought I > understood, > > is that in VS, in the solution explorer, when the user presses > > shift-escape to close it, the focus does not move to > anything useful, > > so WE keeps reading the solution explorer window. If this is the > > case, then I still believe that registering a cursor key is > the best > > way to handle this; in your event handler for the cursor > key, you can > > use a timer set for 50 ms for example, to then cause a > routine to set > > focus where you think focus should go. the timer gives WE and > > solution explorer just enough time to finish handling the > closing of > > the solution explorer window, before you try to move focus. > > > > hth, > > > > Chip > > > > > >> -----Original Message----- > >> From: RicksPlace [mailto:[email protected]] > >> Sent: Sunday, June 10, 2012 5:38 AM > >> To: [email protected] > >> Subject: Re: A VBS and Wrappers Question > >> > >> Hi Chip, Steve et al: > >> OK, I have tried most everything I can think of, including most > >> recent suggestions about CursorKeys. > >> I watched for a UIA OnFocus Change event and if the > AutomationElement > >> is off-screen I stopped speech and routed focus to the > MainWindow's > >> MenuBar. > >> This works unless I close the MenuBar. > >> Instead of hearing nothing and having nothing happen when > I hit enter > >> on the empty MainWindow, focus is returned to > SolutionExplorer, the > >> item focus is transferred to is spoken and hitting enter activates > >> that hidden and disabled object which is what I was trying > to avoid > >> in the first place. > >> So, I can get the off screen stuff to not speak easily > enough, I dont > >> need to use the Keyboard Input at all.But, to stop the non-spoken > >> and hidden object from being activated I think I need to trap the > >> keystrokes and have nothing done if a key is pressed while > the object > >> is off-screen and disabled. > >> I think this requires trapping the KeyStroke(s) and then not doing > >> the action in the Target Program if the object is > disabled and, or, > >> off-screen. > >> So that is where I am this morning. > >> I ask myself if I am using the KeyProcessed method > improperly or if > >> there appears to b4e a bug in the way WE is handling it and I just > >> dont know. > >> Perhaps there is some other way around this but first things first. > >> Do we have a bug in WindowEyes or am I misunderstanding the > >> KeyProcessed Method and, or, using it improperly. > >> I will try and figure better tests to figure that out > today or watch > >> some baseball, not sure which would be more fun - grin. > >> Later and thanks for all the help. > >> Rick USA > >> > >> I might be able to watch for an event to occur like the > Hiding of the > >> Solution'Explorer Window since I think I remember that > occuring in my > >> initial WEEvent Analysis tool output for this SolutionExplorer > >> testing prior to doing any coding. > >> I have been able to trap a UIA action, or even a > KeyProcessDown event > >> key stroke, speak nothing if the object is hidden and > route focus to > >> the MenuBar for the Main window since nothing else is open on that > >> window. > >> This is pretty close to what I want. But if I close the MenuBar, > >> instead of reading nothing or the MainWindow TitleBar focus is > >> returned to the hidden and disabled SolutionExplorer > except that is > >> not hidden nor disabled even though I think the Properties > indicate > >> it is still hidden and disabled - it is still on screen and active > >> even though the properties say it is off screen and disabled if I > >> remember correctly. > >> > >> > >> I have gotten\ > >> l Message ----- > >> From: "Chip Orange" <[email protected]> > >> To: <[email protected]> > >> Sent: Saturday, June 09, 2012 7:48 PM > >> Subject: RE: A VBS and Wrappers Question > >> > >> > >> > Hi Rick, > >> > > >> > I think Steve was saying, if you want to write your app in > >> VBS, then of > >> > course there are functionalities of UIAutomation which you > >> can't access. > >> > So, you would need to write a relatively small vb.net > module which > >> > accesses this functionality, and makes it available as > methods and > >> properties of a > >> > class you have defined, then you register an object of this > >> class as a > >> > shared object. This module would be a separate .exe which > >> would run each > >> > time your app runs, so your app could then get to this > >> object you shared, > >> > and thus use the methods and properties you defined to give > >> your app the > >> > functionality it would need in order to do whatever it is > >> you want to do. > >> > You get to bypass all of the Iaccessible headaches this > >> way, but you are > >> > essentially still having to write a wrapper. > >> > > >> > I think you'll find it easier to try to use the WE objects > >> (such as the > >> > cursor key I talked about in a separate thread) from within > >> a vb.net app, > >> > before trying this split approach. > >> > > >> > hth, > >> > > >> > Chip > >> > > >> > > >> >> -----Original Message----- > >> >> From: RicksPlace [mailto:[email protected]] > >> >> Sent: Saturday, June 09, 2012 8:12 AM > >> >> To: [email protected] > >> >> Subject: Re: A VBS and Wrappers Question > >> >> > >> >> Hi Steve: > >> >> this is getting way more complicated than I think I want > >> to deal with. > >> >> I am not sure about WE Buggs, my own understanding of some of > >> >> their Object Model Documentation and the nasty > limitations of WE, > >> >> VBS and .net or even native COM Objects trying to play nicely > >> >> together. > >> >> That said, > >> >> I think I used a Standard .net executable calling into it's > >> >> functions or subs from a VBS App a long time ago but > dont remember > >> >> for sure. > >> >> I just read a little about IDispatch to try and understand the > >> >> problem and found IDispatchx, think that is what it is called > >> >> which adds extensions to IDispatch to make COM objects > available > >> >> to scripts like VBS. > >> >> 2 questions: > >> >> 1) Did you used the native UIA DLL or did you use the .net > >> >> Framework Automation Namespace to get at the UIA Elements and > >> >> Patterns? > >> >> 2) what type of .net module did you create, standard > dll library, > >> >> COM Library, standard assembly executable or other > module type you > >> >> called into from Python to create the "Shared Objects" > methods and > >> >> properties. > >> >> I will do my homework on whatever your answers imply I > >> should look at. > >> >> Thanks Steve > >> >> Rick USA > >> >> ----- Original Message ----- > >> >> From: "Stephen Clower" <[email protected]> > >> >> To: <[email protected]> > >> >> Sent: Friday, June 08, 2012 8:19 AM > >> >> Subject: Re: A VBS and Wrappers Question > >> >> > >> >> > >> >> > Rick, > >> >> > > >> >> > In brief, VBScript can only take advantage of frameworks > >> >> which expose > >> >> > themselves through COM Automation. UIA does not, hence the > >> >> need for a > >> >> > wrapper of some kind. If you wanted to use VBScript or > >> JScript, the > >> >> > wrapper would need to expose sufficient methods and > >> >> properties of your > >> >> > UIA object. Alternatively, using .net, you could create a > >> >> Window-Eyes > >> >> > shared object to do the same thing. This, imho, would be > >> >> much easier. > >> >> > I have done this with python and it worked very well. > >> >> > > >> >> > Regards, > >> >> > Steve > >> >> > > >> >> > > >> >> > > >> >> > On 6/8/2012 6:26 AM, RicksPlace wrote: > >> >> >> Hi Guys: > >> >> >> After struggling with UIA in my External script I am > >> wondering if > >> >> >> there are unique advantages to creating a UIA script in > >> >> VBS - that is > >> >> >> one that works with both the WE Object Model and UIA > >> where each is > >> >> >> most appropriate. > >> >> >> I wrote to the UIA Forum hosted by a developer of the UIA > >> >> Native DLL > >> >> >> to ask about a few things including using VBS as a > >> >> scripting language. > >> >> >> He said that VBS could not access some things without > >> >> using "Wrappers" > >> >> >> which I dont really understand yet. > >> >> >> It sounds like creating a COM DLL or something but I've > >> not looked > >> >> >> into it since I am working with the Managed Code Framework > >> >> for UIA in > >> >> >> my current External Script. > >> >> >> That said, if there are major advantages to using VBS I > >> >> might go that > >> >> >> route downline as I learn more about UIA. > >> >> >> Do any of you have solid experience creating "Wrappers" and > >> >> >> especially related to accessing UIA or Managed Modules? > >> >> >> The Microsoft Programmer's name is "Guy" and here is what > >> >> he wrote back: > >> >> >> ... prior stuff unrelated to vbs ... > >> >> >> Regarding VBScript, I don't believe the native-code UIA > >> API can be > >> >> >> called from VBScript. > >> >> >> VBScript requires the COM objects to support the IDispatch > >> >> interface, > >> >> >> and the native-code UIA API doesn't support that. But > >> >> while I've not > >> >> >> does this myself, you should be able to call a COM > wrapper from > >> >> >> VB.Net which calls into the native-code UIA API. > >> >> >> I have some C# samples which call into a COM wrapper like > >> >> this. For > >> >> >> example, > >> >> >> > http://code.msdn.microsoft.com/Windows-7-UI-Automation-9ce18fd5 > >> >> >> and > >> >> >> > http://code.msdn.microsoft.com/Windows-7-UI-Automation-9ce18fd5 > >> >> >> . There a couple of different approaches for generating a > >> >> wrapper for > >> >> >> the native-code UIA API, and I've described these up at > >> >> >> > >> >> http://social.msdn.microsoft.com/Forums/en-US/windowsaccessibi > >> > lityandautomation/thread/c3f142e1-0624-4ec5-a313-482e72d5454d > >> >> >> and > >> >> >> > >> >> > >> > http://social.msdn.microsoft.com/Forums/en-TT/windowsaccessibilityand > >> >> >> automation/thread/5b043035-b1eb-4c6c-944c-5ce8df28b1ee > >> >> >> . > >> >> >> If you do generate a COM wrapper and reference it in > a C# (or I > >> >> >> assume a > >> >> >> VB.Net) > >> >> >> project, Visual Studio's Object Browser will show the > >> >> contents of the > >> >> >> wrapper, and Intellisense works in VS to help write the > >> code which > >> >> >> references the wrapper's data types. > >> >> >> ... rest gets into the VS Forms Designer... > >> >> >> First, it sounds like the "Wrappers" are COM objects > like what > >> >> >> WindowEyes should be implementing rather than a script but > >> >> I am not sure. > >> >> >> Second, as VBS Programmers have you developed Wrappers in > >> >> VBS to get > >> >> >> at functions inside other COM Objects like Guy mentions? > >> >> >> I have not done this since my script is already in Managed > >> >> Code but > >> >> >> would have to do it if I switched to VBS unless GW has > >> >> already done > >> >> >> it within their Object Model somehow. > >> >> >> So that is my question, has anyone created COM Wrappers > >> over DLLs > >> >> >> using VBS and does this sound like what Guy is describing > >> >> in the Forum reply. > >> >> >> I will go look at his examples, actually I peeked at them > >> >> and that is > >> >> >> why I am pretty sure they are COM wrappers but would like > >> >> to know it > >> >> >> can, has, been done in VBS before I even consider working > >> >> in VBS to > >> >> >> create a UIA / WE Object Model script since it might > >> add too much > >> >> >> complexity to the project. > >> >> >> So, let me know what you have done with this technical set > >> >> (COM Wrappers" > >> >> >> in VBS. > >> >> >> Later Guys: > >> >> >> Rick USA > >> >> > > >> >> > -- > >> >> > Stephen Clower > >> >> > Product support specialist & App Development GW Micro, Inc. * > >> >> > 725 Airport North Office Park, Fort Wayne, IN 46825 > >> >> > 260-489-3671 * gwmicro.com > >> >> > > >> >> > > >> >> > >> > > >> > > >
