This post is more for my curiosity with regards to the “wait for element” activities. I always use it whenever I am programming the workflow to act on an element–be it web or interface. I am curious… when would they not be needed? Because I have to always use these activities. The reason I bring this up is I feel that it should be more a parameter that is automatically programmed into the actual actions as opposed to being its own activity. Thank you in advance for your input on this as well as your consideration on enhancing the activities we have built into the system.
1 Like
Hello @BrandonTerry, very nice topic for a discussion! “Wait for element” activities are great to manage delays dynamically in our workflows. I would use them when there is a transition on the web page or desktop app. Maybe, I would use them on only one element to confirm that the web page or windows app is fully loaded and not on every element. Could you please elaborate more about how do you think this logic could be implemented in each activity? Setting a configurable timeout and catching the exception when the timeout is reached?
2 Likes
@g.melihov , @Fernanda_Costa , I think we spoke about this recently. Do we need to add this to our future roadmap, team?
@BrandonTerry , it is interesting to know about the use cases here. For instance, our desktop activities already have a default timeout of 10-15 seconds before falling with an error. It means, that you don’t have to add the Wait for element activity for every single action. There are elements that always pop up very quickly (1-2 seconds) so the default timeout is always enough.
Could you share more details on the use case?