Hi Chip,
Originally Rick was attempting to use the WMI key processing and WMI
extensively uses the Async event which like all Async processes returns you
back immediately so you don't get hung up waiting. Something I wanted to use
in the Uninstall program but found out it is not coming back inside the WE
object model. But comes back outside of it.
The other solution you suggested is the best way around it, for I use it
as well. As you pointed out, in the end the ultimate solution is to force
focus to another place. The delay is always used to insure closure of the
original event and window. Moving on to what is the million dollar question.
The reason why I mentioned if nothing else there then create one.
But the WMI thing came up originally and the reason why I had mentioned
it. It is an interesting project that plays with some very touchy timing
issues. As I was searching some of this stuff my old computer died in one of
those single tone crashes, probably the very timing issue embedded in this
entire key discussion.
Good luck Rick, and Happy Hacking!
Bruce
Sent: Sunday, June 10, 2012 2:38 PM
Subject: RE: A VBS and Wrappers Question
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
> >> >
> >> >
> >>
> >
>
