We at UiPath like debugging. And we like it even more in 18.3. Without further ado…
New Default Debug Layout
When you hit debug in 18.3 you will notice a new default layout that we think you will like. We have split your screen into 3 sections and kept only what’s relevant while debugging:
- Locals panel – left section
- Canvas – middle section
- Output panel – right section
What’s more, you can edit this layout any way you like and Studio will remember your settings. Here’s how we like it:
This brings more space and focus on what really matters during debug.
Execution now stops before breakpoint
Up until 18.3, when a breakpoint was hit during debug, the activity was already executed. We heard your pain around this and we’ve changed the behavior. Debug is now suspended before the actual execution of the activity where you’ve set your breakpoint and the activity is highlighted same as before.
Step Into and Step Over
We’ve tweaked some things for the sake of simplicity and usability.
Before 18.3 Step into used to do 2 steps for each activity. That meant highlighting was shown twice for each activity and the user had to click twice on Step Into (F11). First step was showing all local variables values and input arguments for the current activity, second step was showing everything from the first step plus the output values from the activity.
We’ve merged the 2 steps into 1, you click only once, the process will execute the activity and all locals, input and outputs will be shown after the execution.
In terms of Step Over – you can skip over a sequence, a foreach or invoke workflow with Step Over now. Before 18.3 it would have gone inside the workflow definition instead of “stepping over” an invoke workflow activity.
Highlighting behavior changes
We have removed the “Highlight activities” option. Highlighting activities will be enabled by default only for:
- Stopping on a breakpoint
- Navigating with Step Into and Step Over
If you really need to highlight each activity you can enable Slow Step . This will highlight each activity regardless if you have breakpoints set in your workflow or not.
Highlight UI elements stays the same, if you want to highlight the elements on the screen (browser and apps which the process interacts with), you can still choose to Highlight Elements .
Why, you might ask? Here is some valuable feedback coming from you:
- We want to run the workflow at full speed between breakpoints, even in debug mode
- We don’t want to see a bunch of flickering highlights for activities while running at full speed
- Slow speed is too slow, running at full speed with highlighting is too fast
The later feedback is a good Segway into the next improvement – Slow Step speeds.
Slow Step Speeds
So now if you want to highlight each activity, you need to use Slow Step . But like I mentioned earlier, “Slow Step was too slow” and that was a problem. Hopefully not anymore. Use the new Slow Step toggle to shift gears according to the speed you need.
Right Click to Add Breakpoint
Last, we added Right click Activity -> Add Breakpoint contextual menu option. Hope this helps, it sure does help us.
Feedback? Impressions? Thumbs up? We’re all ears!
Thank you again for your valuable feedback along these years and keep it coming!
