Debug stopped on a breakpoint, yet it's not highlighted in the breakpoint list

During a debugging session, I usually have to deactivate breakpoints (without deleting them), to make debugging more dynamic or whatever the reason but the case is that I might need to reactivate them later and this is easier than having to place them again in the right activity.

As the right-button menu option “Toggle breakpoint” is NOT realiable (and this should be addressed, too, as “toggle” could mean both “toggle it on and off” or “toggle the existance of this breakpoint”, which is, by the way, what the option does) and it’s merely placing or deleting a breakpoint but NOT deactivating them, I have to do this from the breakpoint list on the “Breakpoints” tab.

Until now, the current breakpoint where the debugging session stopped in was highlighted as bold text in that list, so it was easy for me to identify it and disable it. But now, it seems that randomly it doesn’t happen anymore. Looked at the attached picture: the whole breakpoint list is displayed, but none is highlighted, though the execution is stopped in one.

I’m in the last Studio version.

Is anybody paying attention to this at all?

I can confirm, with my Windows, non-legacy project, that when stopping on a breakpoint during a debug session the breakpoint won’t be highlighted anymore in bold letters in the breakpoint list.

Consistently happening to me in the last 2023.10 Release update.

I never noticed this.

I do see a breakpoint in the Framework/Process.xaml, is that where your Invoke Power Shell activity is?

Hey @pere

Is it also happening for a completely fresh project, or only on an older project? I am curious because I can’t immediately reproduce this on a fresh project, and was wondering if there might be something more specific to this issue.

This is converted from a Windows-Legacy project; I’ll try to try it later in a fresh, new project.

Edit: seems not to happen with a new, Windows non-legacy project from scratch:

Although this one only has this activity and this breakpoint.

I think I already reported this, but no success.

While debugging, when stopping on a breakpoint, Studio sometimes “highlights” or displays the name of the current breakpoint the execution has stopped in in bold letters; some other, randomly, it’s displayed the “normal” way. This happens randomly. It’s a pity that it’s not always been highlighted because, when the list is longs, it’s difficult to identify it when you want to enable or disable the breakpoint (not merely deleting it), and there’s already a MISSING functionality of doing this when right-clicking on the activity itself, as that only allows to place or delete the activity, which is a pity too, making you lose whatever condition you had on that breakpoint, etc., apart from a low-quality behaviour, as it should always work the same: if it gets highlighted, then ALWAYS highlight it when stopping on it.

Since November no one took care of replying about this. I’m still experiencing this to this date.

In Studio 2024.10.1 this bug still exists:

During a debugging session, when it stops on a breakpoint, you should it highlighted in bold the “Breakpoints & Bookmarks” list.

But this doesn’t happen most of the time.

Many times it’s very difficult to identify what part of the code we are in as this doesn’t work and there may be a lot of breakpoints in the list and many activities with the same name.

This is so straightforward the it isn’t understandable that it wasn’t addressed yet.

Have you tried using when execution is paused during debug? This will focus on the location where execution is paused. It also works with Alt + F10

No. It doesn’t work. Here you have a screenshot. I’ve clicked the “focus” button a million times. It doesn’t appear highlighted in bold in the “Breakpints & Bookmarts” list, while it randomly does.

Thank you @loginerror . The underlying explanations that make this so hard to polish are out of my knowledge.

Now that I caught your attention, and as this affects to the last, brand new version, would like to inform you that the “breakpoint highlighting mechanism”, that used to work randomly befor, still doesn’t work:

Excuse me again because of my arrogance, but again, even if I don’t understand the underlying mechanism that causes this, it doesn’t look like soooo very big deal for me to fix these annoyances.