MS UI Automation- AddAutomationHandler not firing

I'm using Microsoft's UI Automation tools to add change handlers to a textbox. The code is below:

            // Get a reference to the textbox.
            var textbox = window.FindFirst(
                TreeScope.Descendants,
                new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Edit)
            );


        // Bind a property change handler to the textbox -- this works great
        Automation.AddAutomationPropertyChangedEventHandler(
                textbox,
                TreeScope.Element,
                (o, e) => { Console.WriteLine("Textbox value property event"); },
                ValuePattern.ValueProperty
            );

        //A different way of binding - why doesn't this fire?
        Automation.AddAutomationEventHandler(
                TextPatternIdentifiers.TextChangedEvent, // is this the right event?
                textbox,
                TreeScope.Element,
                (o, e) => { Console.WriteLine("Text Changed Event (I want this to fire please)"); }
            );

Whenever the textbox is changed, the event handler added by Automation.AddAutomationPropertyChangedEventHandler fires just fine, but the event handler added by Automation.AddAutomationEventHandler does not fire.

Do I have to listen for a different type of event here? Which event should that be?

Upvotes: 4

Answers (3)

Rivki Aizen

Reputation: 3

for your question:
I found that when element.GetRuntimeId() length is 0 , it is not firing, that is why AddAutomationEventHandler is not working for that element.
I hope I helped you

Upvotes: 0

Guy Barker - Microsoft

Reputation: 574

The AccEvent tool is indeed extremely helpful. It's certainly got room for improvement from a usability perspective, but even so, it can still help you learn exactly what UIA events are being raised by UI. And this includes helping you become aware of what events are not being raised by UI when you would have expected the events to be raised. As you point out, a Button might not raise an Invoked event when it's invoked, which is awkward for you. Unfortunately, I don't think there's a great answer to why certain events don't get raised. Ideally the UI framework being used by the UI controls would raise all appropriate events. For example, I just pointed AccEvent to the OK button on the Run dlg, and invoked the button. The screenshot below showed me that the Invoked event got raised when I did that.

I'll bet whoever wrote the Run dlg didn't explicitly do work to raise that event, so some part of the platform is doing that for the dlg.

On a side note, it's useful to remember that often when a button is invoked, the button's going to immediately go away, (just as in the case of the OK button on the Run dlg). So if you receive the Invoked event and then try to go back to the element that raised the event in order to get more details about the element, that will fail if the element no longer exists. This is where it can be helpful to request that data about the element is cached with the event at the time the event's raised.

Similarly, if I point AccEvent to a Button in a XAML app, the Invoked event gets raised when I click the button, as shown below.

But if the UI framework, (or some custom UI that looks like a button,) doesn't raise the Invoked event when the button's invoked, there's nothing you'll be able to do to get the event raised. UIA simply channels data and events from the UI to your client code, and the UI just might not raise the events. In that case, I find it can be interesting to take a look at what events are being raised in the particular scenario I'm interested in. While the event I really want might not be raised, perhaps there are other events that I could react to, to still achieve my goals.

Thanks,

Guy

Upvotes: 3