Are Automation IDs supposed to be unique amongst sibling automation elements for every instance of the application I have spotted a couple of cases where different automation IDs get generated for the same AutomationElement during different instances of the application.

How is the Automation ID generated Can someone please clarify


Re: Microsoft UI Automation Non-unique Automation ID

Marco Achtziger


you only can influence this if you alter the source code of the application.
This happens when controls are dynamically added to the UI. Then every time the control gets created a unique ID (typically a 7 digit number) is created for it.This is what i encountered. Setting the Name property on the controls also sets the AutomationID but you only can do it in the code of the application.

If you do not have access to the source code you have to search for the controls by type or you create a map of the UI where searching with regular expressions is possible. Maybe there are other solutions. But that's what i did.

Re: Microsoft UI Automation Non-unique Automation ID


Thanks for the prompt reply. So if a unique but different automation ID gets created every times a new control gets dynamically added to the UI, it is difficult for a UI Automation client to carry out a record & playback functionality based on Automation ID, correct The client will have to rely on Name, ClassName and Control Type to correctly identify Automation Elements then, and NOT Automation IDs. Similarly UI test scripts based on UIAutomation should also identify elements based on other parameters then.

Would that assumption be right


Re: Microsoft UI Automation Non-unique Automation ID

Marco Achtziger

IMHO i would say yes. ;-) As long as you cannot alter the code of the SUT you have to find other possibitlies to identify elements. You can create a map of the UI and use the path information (if applicable), the type, the value when it is recorded and so on. In UIAutomation you should also think about using the name property.
I also encountered similar problems in commercial test tools. So i think this is nothing UIAutomation specific.

Re: Microsoft UI Automation Non-unique Automation ID


Yes here to - I use all the properties mentioned to try to identify controls. Much of my work is with web-pages where the AutomationID is usually blank.


Re: Microsoft UI Automation Non-unique Automation ID

Karl Bridge - Microsoft

Please see the AutomationID article at This may help explain some of the issues you are encountering based on your expectations of the AutomationID property.

Re: Microsoft UI Automation Non-unique Automation ID

Mark Asztalos

About the AutomationId topic, I have expresioences. I write a ui tester application, and I have to identify each AutomationElement in any running instance of the application. I found that I only can do it with AutomationId. Becouse a map of the ui and the ControlTypes will not work 100% sure and I've read that the order of the elements in a Tree (created with TreeWalker) is not determined. So the only way is to use AutomationId and "ask" the developers to name the elements. What do you think about it

I will start a new thread concerning that question.

Re: Microsoft UI Automation Non-unique Automation ID

Marco Achtziger

To ask the developers for naming the controls is the best way i think. When the control has a unique name (AutomationID or something else) which can be identified from UIA many problems disappear.
About the map of the UI. I use it heavily on more than one application and it works reliable. I also have an improvement in performance because i know which way to go down in the UI to get a control and i do not have to search it with UIA.

Re: Microsoft UI Automation Non-unique Automation ID


Are you talking about GUI id, Clsid or something else.

Again there is a fair amount of scope to register in case of different instances of the app

Re: Microsoft UI Automation Non-unique Automation ID

Marco Achtziger

I am talking about giving the controls identifiers which will be the same after every start of the application. Forcing an AutomationID for a control is the best way. How an AutomationID is obtained by UIA is described in the documentation.

Re: Microsoft UI Automation Non-unique Automation ID


Hi, this is an excellent post. Can you tell me if there is any more direct way to set the control id (automation id) assuming that I do have access to the source code

Here's the situation, I wrote a piece of software for a consulting firm in C#, and used the form generator to create the form. There is no option in the properties to set an id, and I tried to affect the control programmatically as well (i.e. myControl.somepropertyforid = id) but there's no property in the classes that allows you to get or set a control id.

You had mentioned that setting the name of the control statically affects the id. I have set the names of my controls, and if I run Spy++ over the controls (close the product, restart) the id's are still changing. There must be some way to set a static id pool in a resource file or something, no



Re: Microsoft UI Automation Non-unique Automation ID


When I first started with the UI Automation Classes, we identified what the main problems are when steering the UI.

Number 1, is the automation id. When having to recognize controls, this is the way to go, instead of having to use multiple properties/regex,...

So we sat down with development and explained that in order to make this work, we needed to work together and they should have the reflex to give each control a unique name (even dynamic ones) and also understandable! e.g SearchButton instead of btnSrch or something like that...

Ofcourse when you have a large project, they can't just change everything right away, so we did it on a step by step basis, where if we needed a certain set of functionality in the UI that was not automatable, they would add it for us.

And it has paid off, I don't have lots of problems with controls that need identification and it's much easier/understandable to code a script that has a logical unique name.

And new products/functionality already have it in because of the 'mentality change'.

So I would recommend that you sit down with development to discuss this, it has lots of advantages.

Ofcourse, for the external components/tools, there you will have to find a way around because that's something you can't do much about. :-s