Chapter Eight selectors. In this chapter, we'll be giving an introduction of what selectors are. We will be discussing different ways to stabilize a selector. We'll go through the differences between full versus partial selectors. And we'll also talk about wildcards and indexes in selectors. Introduction.

A selector is an XML string, which contains some attributes that help the UiPath workflow to identify the UI elements that need to interact with the target application. A selector may have as less as two attributes, or could have as many as hundred attributes. So just to give a quick overview of how a selector looks like, you can check this out. Right for a notepad document. This is how a selector looks like. Right to understand what selectors are the most must first discuss what is the structure of external applications.

So, an external application may have user interface elements like text fields, checkboxes, menus, etc, each having their own purpose and capabilities. These UI elements are built using containers one inside the other. Inside containers we have variety of UI elements with specific attributes describing their properties, capabilities, and associated traits. The selectors include a combined range of all this information to be able to identify the UI element with maximum efficiency. elements may contain other sub elements with their selectors. to direct our actions to the specific UI element, we must cautiously select the selector to the most granular level pointing to it.

You can also draw an analogy of structure of UI elements with web design. concepts using HTML and CSS. Right? selectors are generated and optimized automatically for all interactive activities. That is, wherever it is needed to interact with an external application selectors would be associated. However, they need to be debugged.

And quite often, if they don't work as expected upon re execution of the workflow. They need to be changed. To understand selectors better, let's go to UI explorer in our UiPath studio, which is right here. So in here, the leftmost pane, right describes the visual tree which represents the hierarchy of UI elements as mentioned while discussing the element structure. Right. You can see that for let's say, for this notepad document, we have this edit and we have menu bar title.

Are many of our application a table text and scroll bar, all these different elements that are there, right? So, you have like in the title bar you have minimize maximize, if you want to see what the properties of maximize are, this is how it is. Right. So, this selector editor pane, which is this one provides the attributes that are chosen to create a valid selector. The selector editor panel, which is on the right lists, easy to read selector attributes to make them comprehensible to users. Right, you can make an educated guess that you know, this is the name that is given to this button and this is the row, it's gonna be like a push button is the activity that's it's gonna, you know, that will be operated on it and so on.

Right, that's the text that is given. So, the bottom pane with all the XML tags concatenated are called the final selectors. These are modified instantly when an attribute from the selector and it like window is checked or unchecked, such as window, right click additional information. To view the selector of any UI element, you can click the mouse pointer, which is here on the top left corner of the UiPath explorer window and select the UI element. Right? So because all right, so that's how it is like, you know, highlighting and showing what.

Let me find that again. This is the editable text, right? So you can see it automatically gets highlighted, and you can press Escape to get out of it and stuff. Right. So, corresponding selector, you know, with the structural hierarchy would be shown and additionally to highlight the UI element on screen Simply choose a selector. And we can also highlight it.

So if you want to have the UiPath and put the windows right away, you can just click this button, which is the highlight button, and a yellow box appears. And you can also see are the element, the corresponding UI element is highlighted. Right? Just these are like a few tricks that people use to, you know, get to know which element we'll be working on. And just to confirm that, you know, whether the UiPath studio is able to correctly identify the element or not, right. And in case UiPath, is unable to identify the UI element, you can click UI frameworks option from the UI explorer and select the relevant setting.

Like usually it goes with the default but there could be like a change of settings like if this is for UI automation of recent activity visibility, then you can choose that but usually I've never seen working this, the because by default, it always works. Right, you have to you might have to play around with the selectors, which we'll be touching up in a few minutes. So as application interfaces become complex, the hierarchies for the associated UI elements go several layers down. Right. And the selector defines the true path of the UI element based on the containers, other route elements and associated properties, no matter how convoluted they exist in an application. And in final selectors, the first part of the XML tag describes the UI element, the type of the UI element, like, you know, if it is a window, right, then it has it will always have a tag.

That's going to start with this Wi Fi app, right? That means a window application. Other types could be like HTML elements, controls, Java, etc, etc. attributes or properties of the UI element, succeed the type of UI element in selectors and attributes include properties such as application name, title, as you can see right here Class IDs among others, right. So, you have seen how, in our basic recording chapter as well, how we created the selectors, whenever we are in any activity, whenever we are interacting with any target application, then we have to choose a selector or we have to choose the UI element and correspondingly the selector is generated. And going to the UI Explorer, you can highlight you can check whether the correct element is identified.

Even on re execution, you can check whether there was some issue or you know, if UiPath is not able to and if somehow you're not able to comprehend with the error note upon execution of a workflow that, you know, there was some issue with the selector you can always check and debug and make corresponding changes to the selector right. Okay. Next is stabilizing a selector working with activities UiPath explorer provides a complete view of all UI elements present on a screen along with their selectors. Since this is a wholesome place, it is of great benefit to a developer that we don't have to deal with all selectors every time, an activity interacting with external application is used. For this, we have access to selectors presented the Properties panel. I showed that to you in a few, like minutes back, let me show it to you again.

So let's say we have this activity. And here instead of going to the UAV, Explorer, we can get the selector from here, right. The selector editor window, shown in the Properties panel of an activity is simply an uncomplicated view of UI Explorer. There are only two panels within this window, attributes and final selector. The attributes listed here are simply a subset of the complete hierarchy visible to UiPath Explorer. This is a crisper view and makes it Easier to modify the attributes generate the corresponding selector and identify the UI element to perform intended action.

Checking and unchecking these attributes are these. Yeah, these attributes will make corresponding changes to the final selector. It is also worth noting that each attributes shown in here doesn't necessarily correlate to one element of the final selector. In other words, many attributes make clubbed together to make changes to one XML tag. And vice versa is also possible. Right.

Okay. Next, opening UI Explorer, as the name suggests, to view the full list of selectors along with the structure hierarchy, we can click this link. I just clicked on it and here it is. Right UiPath in turn will be redirected to UI UX. For the selected from the activity chosen for per user, if needed, we may have to attach the UI element again, to enable UI paths to provide the selector. Right, that's because in case we are re executing, we might not be able to find the corresponding selector on the screen or the corresponding UI element on the screen.

So that way, we might have to attach it to the live element again, and then we will be able to open it in the UI explorer as well, because for the for the UiPath. Studio, that element doesn't exist at all. So you might have to, you know, identify or make it identifiable for the UiPath to open it in the UI Explorer. If the element doesn't exist, it's not gonna be shown in here, right. Which brings us to the third component of select operator called attach to life element. One of the best features that helps choosing the best selector to be able to identify the correct UI element during multiple executions is provided in this link.

Consider that you need to click a button in an enterprise application and upon re execution workflow errored out stating that the UI element couldn't be identified. In such cases, we can try attaching the selector to that activity with the live UI element currently visible on screen. This in turn will make the selector from current element you know, using the wildcards or D selecting the variable attributes, which could also be the case. Right. And will make it identifiable, the chance that the UI element will be identified correctly upon execution of workflow increases tremendously by this capability with bare minimum effort of manually playing around with the selectors, right, just to highlight how this works. Let's say we have this untitled document notepad document where, you know, in this it's looking at the format by And then clicking on this, right.

So now if I take another notepad document, right. And that's because if you see, it's only working for those notepad documents which have, which are untitled, right? So this is gonna work. But if I say, save it with some name, let's say, ABC, right, and attach it to the live element. And in here is the live element. He says the selector was updated to match the live element, and instead of untitled, now, it says start.

So that means for any notepad documents with any name whatsoever, but it needs to have any name, hyphen, Notepad, that should be the name on the title window, and then it's going to work for those. It's going to click on that. format, but enough any of those no notepad windows, right? So that's how you attach to a live element. So that if there are any minor changes in any of the attributes that are there in the selector, then it automatically gets updated. And it the UI element becomes identifiable for the UiPath studio.

Okay. So I highly recommend that you know, you use this attached live element and play around with it. Next, we're going to talk about full versus partial selectors, right, full selectors. Full selectors refers to the inclusion of all the elements needed to identify a UI element, including the root level container. We also mentioned this in the recording chapter, right? That basic recording supports full selectors.

And to showcase how it looks like I have actually chosen this as from the basic recording itself. And you can see there is a window application, notepad Dotty xe and all the you know, for the format but just for the Format button, you see we have like the whole container shown in here. But say if I take the desktop recording, and I take this, I don't want any anchor and cancel this I should do and if you see in this, this is the same format button, but this time it doesn't have the notepad daddy xe and all the the container which was at the top posts are the root most level because we haven't attached window element which is acting as a container and sort of redirects or first it's going to find that window which is going to have untitled notepad and as per this workflow, and IT drills down to the granular level, and makes our interactions with the UI elements more sophisticated, more better, more optimal, right?

So this is like a partial selector. And the one in the basic recording which we showed just now was full selector. So partial selectors include only those elements associated directly with the UI element. They do not include root level windows or containers and their attributes. And this is because they're generally included in the containers separately, right? And uncompelled, the full and partial selectors it can be observed that the first XML tag describing the Windows application attributes is not available in purchase electro Other than that, they have precisely the same you know, capability and they accomplish the same task.

Okay. This brings us to the next topic, which is wildcards. So, there are various ways in which are selected As customized, this is important to build reliable bots. As we can't rely on a process that works say only 80% of times, there may be some changes in overall look and feel, or interfaces of an application. And selectors should be chosen in a way that they should still be able to manage in identifying the current correct UI element, since their internal attributes remain the same. For instance, say you need to input a file generated by an enterprise system automatically every day.

The file name includes a timestamp, which means a different name would exist upon every execution on a daily basis, right of the program. In choosing the selector, we may have the title of the generated document as part of the selected attribute, which upon re execution will fail, as the workflow won't recognize any elements from it. Right because of the timestamp, it's going to be different date and different probably different Time, but at least it's gonna be a different date for sure every day because the task is working on a daily basis, so the selector won't be able to identify. Of course, if it is a full sector affair is taking the title of the window into consideration the title of the file, right in such cases, the best strategy is to use a dynamic selector that possesses of varying value and can accommodate changes to recognize the correct file upon each execution.

Wildcards provide such capability. wildcards in any generic programming language represent an unknown type. This helps in analyzing the pattern of UI elements and AIDS in recognizing it more efficiently. There are two major wildcard characters used in UiPath. So first is the star. Right?

And star can replace any number of characters including no characters, while the question mark replaces exactly one character and the character needs to be there. The no character possibility doesn't exist for question marks. So, you can say wildcards can replace parts of an attribute within selector that changes over time. And the user may not know of it until runtime. Let's continue with the instance where the file was generated right and we just used it in here, where if we have to make this you know, workable for all the notepad documents for any of the titles, we can simply make, you know, like in here in the title, you can simply make it as star and that way are, you see correspondingly the added attributes. For this particular this particular attribute of the selector automatically got changed, and now all the titles are going to work.

So either you can do this or adapt to live element. Either ways, they're gonna work They play a huge role, trust me, because you will be going through a lot of different files. And you don't want to input each and every file, it's never a good idea to use static values for a selector or even for your variables. When you be dealing with large, complex automations. You want to keep them as generic as possible, you want to make them being able to correctly identify the UI elements are correctly able to identify the files, use wildcards so that you know, you can get to, let's say, a specific directory or to a specific location and can select the file based on the input fields that are provided. Which in this case, if it is a star, then automatically all the files would be selected and that's what if you want as per your business need, that's how it should be accomplished.

Right? additional information is the genuine web automations we mostly use wildcards in selector attributes, since we have a lot of varying color intent, such as placement of search boxes, window titles, possibility of some content carried forward from the last browser window we were working on, etc, etc. legibly, we can use attach live element option to let UiPath create selectors with wildcards for us. But the concept certainly comes useful to validate and or make any ad hoc changes needed in the UI identification process. This brings us to the last topic of this lecture index attribute. As discussed in arrays under data types chapter, and index is used to identify the position of an element.

In case of selectors. It defines the number of element it needs to pick from a container. In many cases, the index element comes firsthand from the UiPath itself, which tells us that there aren't enough attributes UiPath could find for precise identification of that element and in such cases, they are Line activity depending upon the positioning of an element to identify it, it becomes a little unreliable and should be avoided if possible, right. Let's see a quick example of index attribute. Suppose in UiPath, right we have a notepad document open with its font window. And we want to use a click activity, which is gonna click on the 10th lowest element, which is there in these size.

So in this case, 234567, which is 22 in here, right? So let's open the click element and we chose 22. Right and if we go and see it selector, that's how it looks like with all the attributes Right, then window application is notepad and Ctrl, ID and control name and the number that it needs to take. Right? Let's say we take out this 22. Right?

So now if we go and see if the click operation will take place on 22 or not, you can pretty much Imagine if it will, or it will, it will not, I just ran it and didn't click on the 22 element. Right? It's still like that. So, what you first and foremost, the first approach you should do is you should attach it to the live element. And this is where 22 is, and I took out 22. So now, if you see I have an index attribute instead of the name instead of the 22 number, because I took that out.

So it took the index attribute, which means the 10th element of this particular list is being chosen. And it's not a reliable one. But there are cases that you might have to use index attribute right So, you know, if we go and defeat this has been attached to the live element, it has been validated. I mean, we can validate it if we want to. But if you want to check whether it's gonna click on the number 22 or not, let's run this program. And you see, the click operation did happen to give another quick, you know, demo, if let's say we want to click on the fifth element, whichever is the fifth element in that particular container of the size, right within the notepad window, then we just change the index to five, and we run this ever click on the fifth element, which is 12.

Right? So index attribute is also a way to locate UI element based on its position. And it's like, you know, indexes in the selectors. They come with very precise requirements, and users must be very, very careful. while implementing them, if you know that your business requirement that you're trying to implement has a, you know, very concrete requirement that it needs to select the 10th element no matter what the list is or what the container holds, or what different application will be working on what different environment is going to be, if that's going to solve the purpose, definitely cool with the index attribute. Or if there are not enough selectors for UiPath or for you to comprehend and find out the most granular level detail of the UI element, then definitely, it's a it's a decent approach to go with.

Okay.