Feature Idea for Studio during runs in Debug mode

I just throwing this out there as I’m debugging a workflow. It would be REALLY nice if you could be running a workflow in Studio and you see something that needs tweaking or changing or adding anything and you could add a “note”, “comment” while Studio is in Run mode basically.

Basically Step Into and see something … add a note within Studio on the step or something … click on Step Into or Over or whatever.

Then, when done, there is a window you have look at which tells where your Debug Notes are and go forth and be productive in making the changes. It is a pain to have to make Debug notes outside of Studio while testing and flip back and forth … just say’n …

1 Like

Hi @riverrat437,
It is interesting idea :slight_smile: I pushed it to our internal tracker.

Nice one. Thanks for this! Can you give us a few note examples please?

Just a few thoughts:

  • Allow the user to right-click on an activity on screen and a Debug Comment menu option is made available. A small window pops up where they can select a dropdown a “Tag” if desired. Say the list is: Comment, Bug, Enhancement. The default is “Comment”.
  • Studio has a “Debug Dialog” control area available (Not sure what the name should be but “Debug Dialog” seems appropriate possibly) similar in functionality to the Debug Breakpoint management control area. So there is already a similar “control” area already in Studio to base the UI/UX aspects on.
  • In the “Debug Dialog” control area you see a list of the Debug comments that have been added during a Debug run. This screen shows what “tag” is associate with each comment. The “Tag” column can be sorted for easy stacking of the comments by blocks.

Example notes might be:

  • Tag: Bug Comment: The activity is pulling the wrong value from the web page here. It should be pulling out value bhalbahblahbalh.
  • Tag: Comment Comment: There seems to be a missing branch of logic after this activity related to unhappy path logic. Please look into Try/Catch logic to handle this.
  • Tag: Enhancement Comment: While the logic works, please refactor this from a Sequence Diagram and into a Flowchart. The logic within this xaml is wwwwaaaayyyy too complicated for a Sequence Diagram. I think 7 layers of nested If Activities is a little much … just say’n …

I was just thinking about post-Debug and how to handle this “data” fluff within the various xaml files now. What happens when you are “done” and don’t need the dialog anymore. My thinking there is possibly similar to the delete unneeded screen snapshots feature. You could have something that says simply: Purge Debug Dialogs and it prompts for confirmation.

The other things hitting me as I type this up is what about SCC ? My thinking is Debug Dialogs should be in SCC as the person making this comments may be a tester and doesn’t make updates. They only add Debug Dialogs.

And even more so, is this a “Chat” like feature similar to the Comments capability in Word for example ? This goes to the life-cycle question as well. Can others comment back to your dialogs, delete them, etc.

Oh damn, if Studio had integration to a ticketing system that is setup … someone could use a little more syntax to “trigger” that integration within the Debug Dialog to automatically generate a ticket !!

Sorry … a little deeper than I intended this to go but just ideas … Happy Sunday y’all :slight_smile:

1 Like

Great idea!

1 Like

I’m adding this as more context why this is needed. The image below shows a debug session I was running and something unexpected happen. What happened ? The 20-year old POS software client being automated just decided to die for no reason. It just died.

So where I have the Studio right-click context menu showing there would be a menu option for Debug Annotation or maybe Debug Dialog or something.

In there I would add text saying something like this:

The design of this while loop does not take into account the fact that the client can sometimes die here for no reason. This needs to be wrapped in a Try/Catch to capture this issue and setup a functional unhappy path indicating the job failed and needs to be re-scheduled. Or likely better put the Try/Catch higher in the logic as there are multiple places where the client could just die.

The key here is obviously using a Try/Catch to stop the terrifying Hard Error.