Working with windows selectors

Allan Zimmermann

When working with Windows.Get Element you might have noticed there are 2 types of selectors. Long selectors and short selectors. You can control if the recorder should create short or long selectors under Settings -> Recorder Plugins -> Windows -> Create short selectors

Long selectors
With the "long" selector, the robot has to find each element by searching the children.

So it gets the desktop, searches all children for the window, once it finds the window, it searches all the window's children for the next element and so on.

Getting all children is normally very fast, but it does take 20-50 milliseconds and with the processing of the element you end up with 100 milliseconds per element.

When caching is enabled, it will cache each part of the selector, so next time you need to grab something where parts of the selector match, it will be 50x times faster.

For each element, sometimes you need to modify the selector, since the element can change over time ( different automation id's ... Remove name of current customer open etc. )

The good thing about long selectors is you will never risk getting the wrong item, but there is a time constraint and a risk the selector will not find the element due to the selector being too strict.

short selectors
This is enabled by "search_descendants" setting, you set this either under options or in the first selector group.

With short selectors the robot will try and find the window based on processname, and/or the first selector if this is a window.
Next it will search all descendants ( children and all their children and so on ) for the next selector item.

Getting descendants is very slow, and the more UI elements there are, the slower it becomes. But if the "long" selector version is very long, this might be faster.

With short selectors you don't need to update as many things for elements that change over time ( different automation id's ... Remove name of current customer open etc. ) but you also risk finding the wrong element.
There are times where a short selector can find the element every time but a long selector can not. In applications that modify the ui tree structure a lot ( like office applications ) a short selector might be the only option.

Maybe there are multiple panels with a text field named "name" or maybe there are multiple datatables with rows etc. so you have to be very sure, the UI cannot change in a way that will give you more than one hit ( or the wrong hit )

With short selectors there are less selectors to cache, so often getting multiple items will not get faster over time, since cache has nothing to "offer" for helping with finding parts of the selector. ( it will work for the process/first element thou )

Lastly, using * is a life saver in some siturations but don't over use it. It comes at a high cost. The automation framework does NOT understand * or ? .. so everytime you add that, you force the robot to get all elements that match without the field, and then match each result one by one.
So if the selector works by completely removing the field you added the * too, then just remove it to get better performance.

  {
    "ClassName": "Panel",
    "Name": "Customer *",
    "FrameworkId": "XAML"
  }

Becomes

  {
    "ClassName": "Panel",
    "FrameworkId": "XAML"
  }