Element is Disabled, so the Activity Times out Instantly

I’m working on an automation process where the application contains around 40-60 fields or so out of which 30-45 have to be populated with data.

The data in the remaining fields are autogenerated as we enter the first few fields, and this leads us to the problem at hand - suppose I enter data into Business Unit, the Country and Country Code is autogenerated due to some embedded business logic from the application.

While this happens, the bot is unable to enter data into other fields and instantly times out stating that the field is Disabled.

I’ve tried everything, enabling Alter if Disabled, to setting Visibility to Fully Visible, and Wait for Page load to Complete, even adding a check app state, but none of it seems to work.

image

Right now I’ve adjusted everything by using 2-3 second delays which isn’t really the right way to go about addressing this issue. Also, if there happens to be a way to check its state using check app state, it wouldn’t be practical to include one for each field…I don’t think I need to explain why!

So my question is, is there anyway to program UI activities to only interact with the UI Elements once its active or wait until it becomes active?
Where exactly am I screwing up, and how can I become a better RPA developer?

I hope I’ve explained the issue properly, if not please let me know I don’t mind going into depth to explain this problem since I’m pretty sure that there are many others who face this issue as well.

Thanks in advance!

Kind Regards,
Ashwin A.K

Hi @ashwin.ashok ,

Was an analysis made on this manually ? Are the fields disabled for some time when performing manually as well ? If so, what was the time duration observed ?

Maybe also try providing a Delay Before Property for the Type Into Activity and check whether it is able to type the data. If it doesn’t work try increasing the delay by 100 ms and check again. Do this upto the point where the Type Into Activity starts working. We will get a confirmation on whether a Delay is really needed or if there is some other issue that is blocking the typing for other fields.

Also let us know a more accurate Error Description that is been encountered.

Hi @supermanPunch ,

Thank you for your response, I appreciate it.
Yes, the fields do get disabled or greyed out for a short period as the business logic embedded in the application fetches data to fill into the other fields.

Here is the error detail:
The UI element is invalid. Make sure the target application is open and the element is on the screen.

There is no issue with the selector for that particular UI element, and the application is also accessible and I can confirm this since the automation proceeds without any issue on pressing Retry.

As for adding delays, that is how I am handling it right now, but the problem with doing this is I have to add it everywhere, which in turn needlessly increases the execution time.

I was hoping that there was some feature either in the project settings or in the activities themselves that could check if the element it is supposed to interact with is enabled/disabled.

I hope that adds some clarity to the issue I’m currently facing.

Kind Regards,
Ashwin A.K

@ashwin.ashok ,

If the Delay to be provided is greater than 1 second, then maybe an alternate would be to use the Retry option available with Verify execution Property of the Type Into Activity.
image

However, If the application itself is made in the manner as to avoid any updates for a brief period of time, I do not think the Delay can be skipped.

Also, Is this happening after each field entry or only after the first few fields ? Also, Is there a involvement of the Enter key here, In some cases only after clicking on Enter the field values are auto generated. So Perhaps, maybe skipping the Enter Key at the beginning and only keeping the Enter key at the end maybe a possibility ?

The above suggestion is a bit stretched out as we do not know the exact application that is being used and it’s UI screens or it’s visual behaviour, but I hope the idea is understandable.

1 Like

Hi @supermanPunch ,

I haven’t explore the Retry option in UI Activities, and as per your advice I’ll experiment with it.

Also, sorry for not mentioning this before, but the application I’m trying to automate is called Oracle Fusion.

Here is a short example of the auto generation I was referring to:
The field highlighted in red is where the bot passed data->

The fields highlighted in green are where the system auto generates data->

This application doesn’t always respond favourably to selectors set to Default, so I had to change its framework to Active Accessibility to make it work:

image

Also this doesn’t happen for every field, but only for those fields that trigger the business logic to update other fields.

The fields don’t require hotkeys - just setting the UI Activity option to Deselect works. That being said, there are few instance where I had to rely on the Enter Hotkey to trigger the auto generation.

Kind Regards,
Ashwin A.K

Hi @ashwin.ashok

As @supermanPunch mentioned using retry would be good so that it retries after the specified interval again, here as well you have to include each activity into separate retry

One thing you can check is the change in selector when the field is disabled and when it is enabled. There might be some attribute that is set to true or false or 0 or 1 or a class change…which can be used to detect and type into only the valid elements

Again as in oracle fusion generally the fields update once you move out of previous field so include a tab key or deselect to make sure before the next activity starts the ui element changes the state to active to inactive so that bot waits till it is active again if you are able to find a difference between both

Cheers

Hi @Anil_G ,

Thank you for your response.

Adding each activity into retry scope(I’m assuming that is what you are referring to here) isn’t the best way to go about addressing this issue as it increases the dev effort as well as makes the workflow bulky.

Also, the retry scope requires us to pass in a condition i.e it will go on retrying as long as the condition is not met.

If you were referring to the retry present within the modern activities, then that too requires a validation to be set and it again, increases the dev effort.
I was looking for a simpler way to address this issue, but it seems like this can’t be resolved easily.

As for checking the selectors, I did find that the aria-disabled property
is set to true when its disabled, and we could use that but then again adding this check to 40-60 UI Activities translates into additional 25+ Get Attribute Activities to check its state before interacting with it.

I’d also like to optimise the process while I’m at it, but I guess I’m getting a little too greedy with this hehehe

I appreciate your response thought, thank you for the suggestions. I hope UiPath looks into this and comes up with a neater resolution for it.

Kind Regards,
Ashwin A.K

Hi @ashwin.ashok

To start its not madatory to give a confition in retry ypu can leave it and all the exceptions would be caught and retried. But yes it should be added to each activity

Coming to the second one i was not referring to check properties but i am referring to check if any attribute which you can include in a selector directly is different…so that you need not do get attribute activity rather use that attribute with enabled values then the disabled ones wont be identified by the bot. For that we also have to make sure that before this activity starts the button gets disabled which would be possible by exiting the previous activity so that the button greys out. Hope this clears my thought

Cheers

1 Like