I am working in a progress applications and in some cases I need to use the selector options to verify the control properties however the selector gives me unusable informations because this informations does not give me the control name, if it is visible, or if it exists. I would like that you improve really the selector options so that we can have more alternatives to define a control.
Por example.
For me, this informations is not unusable I don’t have all the properties of the control it is very simple information there is not a great value to determinate a specific control because as you can see the informations is very general anycontrol can have the same characteristics.
In the following image I can determinate that It is selected an email field because The tool gives me the real name of the control and other properties that can help me to evaluate a control state
Have you tried inspecting with UiExplorer? You can get all that (and some more, as I also expect other info is available in whichever application your screenshot is from).
Example of a manually built, similar selector (I didn’t go to recreate it completely 1:1): <html title='Sign in to your Zoho CRM Account' url='https://www.zoho.eu/crm/lp/login.html' /> <webctrl id='outertable' tag='TABLE' /> <webctrl id='login' name='login' parentid='loginform' tableCol='1' tableRow='3' tag='FORM' /> <webctrl id='inntbl' parentid='login' parentname='login' tableCol='1' tableRow='3' tag='TABLE' /> <webctrl id='lid' tag='INPUT' class='input usrbx' type='email' />
(other properties like visibility, isDisabled etc. can be viewed from Properties tab in UiExplorer)
But that contains a lot of clutter - this selector will work just as well (auto-generated from IE): <html title='Sign in to your Zoho CRM Account' /> <webctrl id='lid' tag='INPUT' />
What UiPath does with autogenerated selectors is to only have minimum needed information that is required to identify a control in the context - if there’s only 1 control named “Iid” in the searched context (as is the case here), other information is not required and can sometimes work against you (f.e. if layout is cleaned up to have less meaningless nesting [which some frameworks like to add]).
I’m actually glad you don’t need to specify full path, as with some applications that would be 10+ nested tables in, at which point I don’t see most people (myself included) keeping track if it’s correct nesting level or not.
To sum it up UiPath can do that (via UiExplorer) but it is optimized towards UI Automation and not UI Inspection…therefore some properties are removed.
In your example a small layout change may move the EmailInput("lid") out of Cell(2,1) and this is why we remove those properties that are prone to change out of selector.
