Please consider an option to auto-reset !statusOK

In my extremely limited experience, it looks like the minimum extra error handling lines to deal with storing a default value of dynamic elements (that may or may not exist) on a webpage is 4. (please guide me if I’m misunderstanding the situation)…

{ attempt to store a value/attribute…
“Command”: “storeAttribute”,
“Target”: “xpath={ixpath}[{i}]//input[@class=‘itemNumber’]@value”,
“Value”: “inumber”
},
{ go past default store if OK
“Command”: “gotoIf_v2”,
“Target”: “{!statusOK}", "Value": "inumber-OK" }, { store a default value instead "Command": "store", "Target": "N/A", "Value": "inumber" }, { skip to here if default was not needed "Command": "label", "Target": "inumber-OK", "Value": "" }, { reset !statusOK "Command": "store", "Target": "true", "Value": "!statusOK" }, { "Command": "storeText", "Target": "xpath={ixpath}[${i}]//span[@class=“description”]/a”,
“Value”: “idescr”
},…

A few potential feature solutions came to mind, but since I’m not sure of where RPA stops and Selenium starts, these may be way off base, please advise.

  1. could you not allow synatax in a storexxx command’s value (in addition to the variable name) that represents a default value on error? This would look something like this:

{ attempt to store a value/attribute…
“Command”: “storeAttribute”,
“Target”: “xpath={ixpath}[{i}]//input[@class=‘itemNumber’]@value”,
“Value”: “(inumber, “N/A”)”
},

  1. To at least avoid having to repetitively add an additional command to reset !statusOK, would it be possible to key off of the unused value in label commands to do this automatically? This would look this:

{ skip to here if default was not needed
“Command”: “label”,
“Target”: “inumber-OK”,
“Value”: “!statusOK”
},

Thanks for your consideration!

Actually, what you ask for already exists: !LastCommandOK (It is deprecated but still works).

See here: What's the difference between !statusOK and !LASTCOMMANDOK? - #2 by ulrich

Greetings, Ulrich. I’ve been trying to avoid deprecated features because, well, they’re deprecated, all my code is new, and I want it to be as stable and long-lived as possible. Isn’t avoiding deprecated features considered best practice?

I understand the necessity of refactoring to improve a product, but not the act of removing functionality, which seems to be the case with deprecating !LASTCOMMANDOK command and replacing with !statusOK.

!LASTCommand functions how I would expect a status check flag to work. I don’t understand the logic involved in replacing it instead of simply adding !statusOK as an additional flag for different purposes.

So, unfortunately, you didn’t really address my proposal for a way to maintain functionality and lessen code complexity.

The solution is very easy use this command periodically

{
“Command”: “store”,
“Target”: “true”,
“Value”: “!STATUSOK”
},

And you can reset !statusok when you need.