I believe what you found Bruce is specific to WMI and has nothing to do with Rick's situation or anything else.
Chip > -----Original Message----- > From: BT [mailto:[email protected]] > Sent: Sunday, June 10, 2012 6:57 AM > To: [email protected] > Subject: Re: A VBS and Wrappers Question > > > Hi Rick, > > The one thing I found out and mentioned before, GW Micro > is blocking the Async event, but works outside of the WE Object. > > The Async event is that very important event that tells > you immediately that something has happened; for control is > returned immediately while the event or process is running. > This Async event is inside the WMI name space and the reason > why I had mentioned it earlier. > > I firmly believe the WE Object is hogging that event and > it is not bubbling up and out of that object. At least GW > Micro could at least have a property or and event made that > is a clone, or forces the event to bubble out of the WE > Object. At the moment it is not. > > I suspect that this event drives the WE Object model and > is used extensively. > > The only other suggestion is if this screen window that > is deactivated keeps getting focus then make your own dummy > window that attracts the system focus event so it does not > fall back to the only thing on screen, the disabled window. > This probably is why it keeps falling back to it because it > is the only one there on the Desktop and thus gets all the attention. > > I hope this can help, for the Async event is blocked > inside the WE Object, but it sounds like you don't need it > any more since you finally got the key to do what you wanted > it to do, I think. > > Sincerely > Bruce > > Sent: Sunday, June 10, 2012 5:37 AM > 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 > >> > > >> > > >> > > >
