Why AutomationProperties Are Necessary in WPF

Question

In my understanding, AutomationProperties can be used to identify UI Automation client control names.

I want to understand the need to create a separate set of automation properties and not use x: Name for the same purpose.

Answer 1

Let's look at a text box, in your application this is PhoneNumberTextBox, and you also have PhoneNumberLabel and PhoneNumberValidationTick. Then they are displayed inside the group field with the inscription "Client"

A blind person trying to use your application would like the screen reader to say “Customer phone number” when they are inserted into the text field, just like a tester writing an automated user interface test for your application would like to find a text field containing "Customer phone number."

Now, if your application has been translated into German .... Will the blind user not want the screen reader to say “Kundentelefonnummer”?

Now imagine that you changed your application to use PhoneNumberInputControl, most likely you will want to change the names of the control in your code, but the tester would rather want the name of the control to not change ...

So, we need the concept of name used by programs that try to use the "important" logical controls of the application at run time and automate something about how the user interacts with the application.

Answer 2

I believe that my answer came a little late, but I found the right explanation, and I would like to share it with all the programmers to improve their work in this area of ​​automation.

Currently, I mainly work with some automation tools called RPAs, in particular UiPath and Automation Anywhere .

For many months, I struggled with some automation tools because they were developed in WPF and not in Windows Forms , which makes their automation very difficult, and we were very dependent on image recognition not because they were poorly designed or not were working as expected, but because AutomationProperties never considered in any project.

To find the answer to why the controls were not recognized by any RPA, and we were forced to constantly use image recognition , especially in tools like UiPath, which is built into VB.NET , which must have a full connection to Windows, it was incredible to believe that this could not work well, and it pushed me to a deeper investigation of the root cause, and I created the following test case.

A basic WPF application without any automation properties (default), which contains only Grid , Label , Button and TextBox :

 <Window x:Class="UiPathExample.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:local="clr-namespace:UiPathExample" mc:Ignorable="d" Title="MainWindow" Height="350" Width="525"> <Grid> <Button x:Name="button" Content="Button" HorizontalAlignment="Left" Margin="91,60,0,0" VerticalAlignment="Top" Width="75"/> <Label x:Name="label" Content="Label" HorizontalAlignment="Left" Margin="82,121,0,0" VerticalAlignment="Top"/> <TextBox x:Name="textBox" HorizontalAlignment="Left" Height="23" Margin="300,135,0,0" TextWrapping="Wrap" Text="TextBox" VerticalAlignment="Top" Width="120"/> </Grid> </Window> 

Now, if you try to find any control using Spy ++ , Ui Explorer from UiPath, cloning objects from Automation Anywhere, etc. This is your result:

All controls cannot be detected by any RPA or tool. In this example, I use Ui Explorer from UiPath (I could also use Spy ++ and get the same result); however, if you change the code a bit and add all the automation identifiers as suggested on this site:

http://www.jonathanantoine.com/2011/11/03/coded-ui-tests-automationid-or-how-to-find-the-chose-one-control/

The new code will look like this:

 <Window x:Class="UiPathExample.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:local="clr-namespace:UiPathExample" mc:Ignorable="d" AutomationProperties.AutomationId="Window1" Title="MainWindow" Height="350" Width="525"> <Grid AutomationProperties.AutomationId="Grid1"> <Button x:Name="button" Content="Button" HorizontalAlignment="Left" Margin="91,60,0,0" AutomationProperties.AutomationId="btnButton1" VerticalAlignment="Top" Width="75"/> <Label x:Name="label" Content="Label" AutomationProperties.AutomationId="lbl1" HorizontalAlignment="Left" Margin="82,121,0,0" VerticalAlignment="Top"/> <TextBox x:Name="textBox" HorizontalAlignment="Left" Height="23" Margin="300,135,0,0" TextWrapping="Wrap" Text="TextBox" VerticalAlignment="Top" Width="120" AutomationProperties.AutomationId="txtAutomationEx"/> </Grid> </Window> 

And now all the controls become available for Ui Explorer, like the button that I highlighted:

Based on my personal experience, that’s why I think we should use them; especially in those days when RPAs are becoming iconic in any industry. In addition, you will save a significant amount of time for yourself or your team if someone automates the tools that you create in the future, because without these properties, automation will be extremely inefficient, because you will rely on image recognition all the time, since this was in my case.

In addition, here you can find out more about automation properties: https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-properties-overview

Happy Automation!

PS:

An interesting fact in my research is that in any Windows Forms project , the controls are already open for any automation tool without additional effort, and therefore they are faster to automate.