Currently the Wait Screen Text terminal activity just throws an error of “Terminal: Timeout” when the text does not appear. This forces us to put each Wait Screen Text into a Try/Catch in order to give more useful error messages.
It would be extremely useful if the Wait Screen Text activity had a property where we could define the error message to be thrown. For example, if I use a Wait Screen Text to determine if the CIF menu appeared as expected, I could put “CIF menu did not appear” in the error property of the Wait Screen Text activity, and the error thrown when the timeout is reached would be “Terminal: CIF menu did not appear” instead of just “Timeout”
I just installed UiPath.Terminal.Activities 2.6.0 and I do not see a property that determines the error message that’s thrown when the text does not appear.
After doing a test I found that the new feature isn’t what I suggested. The new “feature” is that the error message says “timeout waiting for XXXX” where XXXX is the string you entered to wait for.
This is better than nothing but still doesn’t solve real world usage of this activity. The general reason for waiting for text to appear is to confirm the screen we are on, successful execution of a command, etc
So “timeout waiting for mytext” still isn’t a useful message. I want to be able to configure a CUSTOM message that is thrown when the text doesn’t appear. So I can set it to wait for the text “action successful” and if that text doesn’t appear it throws a CUSTOM message that I entered such as “Transfer failed to post”
“Timeout waiting for ‘action successful’” still doesn’t help me, so I’ll still have to use a Try/Catch to deliver a useful message to my users.
Also, someone should spell check things before publishing:
Removing the “” fixes it, but this will confuse people until they realize what the problem is.
I would say the connection wizard shouldn’t automatically open when the Terminal Session activity is added, and it definitely shouldn’t populate the Connection String property with “”
I’ll have a look at the scenario you are describing. Can you tell me what studio version are you using and the type of project (Windows/Windows-Legacy)?
It can’t break existing workflows unless someone upgrades to the new package - at which point they have to be aware of the potential issues that could cause. And that’s ALWAYS the case when upgrading dependencies.
Also, ANY change to ANY activity could break an existing workflow, so honestly that’s kind of a silly reason not to make useful changes.
Just changing the error message, which you did, could break an existing workflow if someone has a process that expects the old error message.
In this case, the solution is simple. Add the custom error message property, but if it’s blank deliver the standard message of “timeout waiting for…”