The error I'm trying to avoid is basically a USB enumeration thing, I'm power cycling some hardware and sometimes Windows is an idiot and takes forever to see it once it's back up. I don't really want to wait 10+ seconds when this normally takes <5, that adds nontrivial time to the overall test, I want to be able to retry a couple of times and if that doesn't work THEN throw the error.
Anywho, I think I worked it out on my own, though it's pretty kludgey. For the counter I have it set to change the ReportText in the Step parameter, the steps that tend to throw this error directly aren't in the Report anyway and TS doesn't seem to update that parameter at all if you don't tell it to. That lets me build an if/elseif tree that handles the various cases, though it's a little uglier than I really wanted (I could probably make it less ugly by being clever but I just wanted to get it working first).
I also realized that I could just look for the particular step name that threw the error rather than trying to parse the error text itself (both of which the SequenceFilePostStepRuntimeError callback tutorial actually had in it, inside the "Choose Action" step), but I may want to parse the error text later so it's good to know how to access it.
Finally, I discovered that the answer to my second question is "Just don't set the ErrorReported flag", so I don't actually need to include any logic for errors originating in steps that I haven't explicitly listed, if at the end of the callback that flag is still set (plus the various others that indicate there was an error) then the dialog still launches, you don't need to include an "Else" that does it.
So I think my questions are solved, though I'd definitely like to know if there's a better way to include a counter for how many times a given erroring step has been retried.
