The New UiExplorer

i_planned
studio
uiexplorer

#1

Hi @badita, @Cosin

As discussed here are some points regarding the New UiExplorer tool. We feel that it does not work as well as the older version and other improvements could be made:

  1. You have multiple properties belonging to objects but you are now only able to select based on a few attributes. Previously we could easily add attributes such as checked/visibility which at times could help us identify an element or more information about an element. The selector editor is now restricted to the point that you cannot make these changes and whilst you can add them manually you do not always know the exact syntax required.

  2. Validate selector previously highlighted the actual element on the screen. Now it just says that the element is valid but how do you know that it is actually picking up the correct item? What if something has a very similar name and the id changes so actually you are picking up the incorrect element but UiPath Explorer thinks it is valid.

  3. I have always thought that if you change the selector in UiPathExplorer you should be able to press a button at the top to swap the selector with your new information. Instead you have to copy and paste the new text back into UiPath.

  4. With regards to the post by Cosmin at Renaming minor UIPath elements - I didn’t actually realise that this is what was happening. I think that this should be included within the Standard UiExplorer, perhaps you could have a “Compare Selectors” button at the top which would allow you to first select an element and store the attributes, then reload the page or load a similar page and select a second element to compare with. This would help you to see which attributes change and which remain the same. Additionally then you could select Wildcard (e.g. must exist but can be anything) or partial text (e.g. Internet Explorer *) or remove attribute (already can do this). I feel this warrants a further conversation but something for you to think about.

Richard


#2

Again, agree on all of them :slight_smile:

And to clarify for everybody else, #4 is about the Attach to live element part in the other thread.


#3

And a question. How important is the first issue, the missing attributes thing?
You can still manually add attributes but I guess part of the problem is that you have no way of knowing what they are.

And about the rest of the issues, can I assume they are vaguely in the order of their importance?


#4

Exactly - it’s one of those things that you may only need every now and again but when you need it you really need it!! Some of the attributes will obviously never be used.


#5

Regarding point 2, I’d also really like to be able to see multiple highlights when the currently active selector matches more than one element. I think the validator tool currently fails whether the selector matches 0 or >1 elements.

I’ll also make some comments relevant to points 1 and 4 based on a process I’m currently working on.

Included in this process is a highly dynamic web application that makes it tricky to find a selector that is sufficiently specific to locate the same target on similar pages, yet not so generic that it fails to be unique. This is challenging because, for example, the application has no useful URL navigation and some “default” attributes like id are dynamically generated and meaningless. The idx that is automatically added to make the selector unique can be helpful, but also unreliable, and it’s sometimes very hard or impossible to keep it from appearing in your selector using the current choice of attributes. In such cases I feel UiExplorer could use some improvement.

So, as suggested in #1, let me try to improve the selector myself by adding some other attributes from the Properties list and then give me feedback (see first part of this post) about the element(s) it matches. Or try to do it automatically as in #4. I think both of these approaches would be nice to have available in UiExplorer.

On another note, I believe (can’t verify right now) the idx also doesn’t appear in the selector attributes list. This makes it impossible to remove it, though I suppose this is due to the way UiExplorer wants to track the same, unique element you indicated or chose from the tree view. Again, this is frequently very useful, but I would in some cases like the explorer to relax this constraint; perhaps something like a “Track Target Element” on/off switch.


#6

Point 1 should be discussed attribute by attribute. For sure some does not make any sense to be included in a selector: tid, pid, position, app and title, has focus, hWndHandler, wndExtStyles, wndStyles. 2ndly, even if you do include them they are not guaranteed/implemented to work (remember the PID case)


#7

Title is useful for distuingishing against opened tabs in the browser and multiple excel files.
app is used by default in most top level selectors, isn’t it?
position I’ve seen used only dynamically, not directly in selectors.
Rest admittedly looks not very useful or reliable.


#8

Not sure if it belongs here, but is it possible to build an activity that fetches specific type of Element in a page similar to Find Children, but we pass the Element type like Table,DIV etc. We do have search option in UIExplorer, but on an activity level if we can search it would be helpful.It might take a toll in the performance, but just an idea.


#9

Had an example the other day where the attribute of a checkbox was accessible but was not visible in UiExplorer. This value was “checked” and I only found it because I knew that a checkbox has that attribute usually.


#10

Yes, and the oddest thing (I think) about it is they work perfectly in normal execution, but you cannot validate them with either the selector editor or UiExplorer. For these corner cases I now use a small validation workflow that takes a selector string and attempts to highlight that element. This is slightly more cumbersome than the regular process using the editor/explorer, but it has helped with an obnoxious web application that uses custom HTML attributes all over the place.


#11

Richard & sfranzen, could you post a screenshot of UiExplorer with the property explorer pane opened (and pinned), with the problematic element selected? It would help a lot in finding&solving the problem.
Also the version. Thx

something like this


#12

I had a look today and tried to get UiExplorer to throw me the same errors I got before, but somehow this time it worked painlessly.

The Property Explorer showed me the web application’s custom HTML tags I ended up using instead of the id tags, and I was able to type these into the selector expression and validate it correctly. Previously I remember the validator showing me an error dialog before reverting the selector to the default choice, as if I had just used “Indicate on screen” to select the element. Unfortunately I can’t reproduce the behaviour now, but fortunately that means things work as they should! :wink:


#13

I think @adrian is the person to thank :wink:


#14

Well in that case, thank you @adrian! :heart_eyes: :wink: