Bug fix: Breakpoints: Breakpoints set to off(deleted) in the sequence file during sequence file execution don't disappear from the execution view in the execution tab
I'm not able to reproduce this issue. What might be leading to confusion is that the opposite is expected behavior. If you set/unset a breakpoint in the execution view it does not affect the breakpoint setting in the sequencefile (edit time) view. This is because breakpoints set/unset in the execution view are temporary, execution specific breakpoints.
I agree such behavior is a bit confusing and non-standard, so perhaps by default it would be better if the breakpoint settings were linked and only if the user specifically asks for execution specific breakpoints, perhaps via a context menu, would they get such special case breakpoints.
If the above is the issue you are seeing. I'd like for people to kudo this idea if they think it would be better to link the breakpoint settings by default. If someone feels strongly that things should keep working the way they do, please write a comment saying so, and explaining why if possible.
I am very much in favor of keeping independent configured breakpoints for each execution that are separate from the "Default" breakpoints on the sequence file (how things are today). This way you can keep things (breakpoints) separate especially if you have multiple executions happening.
Being able to see and manage these different lists of breakpoints before during and after execution is very important. This is what the breakpoint manager is for. However, because of idea exchange 2044110
it is horribly difficult to manage your breakpoints while doing anything. Open the breakpoint manager to see something, and then you need to close it again before continuing to debug your sequence. Then open it again, then close it again, then open it again, then close it again -- you get the idea.
The other problem that encourages misunderstanding of how breakpoints are held independently between different executions and the sequence view is that the breakpoint manager does not show or allow you to interact with breakpoints for each of the different views. All of my different breakpoints between multiple concurrent executions and the sequence view are all listed in one tree for that one sequence file (ignore calls across multiple sequence files for now because that just makes examples harder). Now if I click to goto that breakpoint (From breakpoint manager) I only ever go to the sequence file view. I can't "goto this breakpoint in execution #3". If I choose to edit a breakpoint, it acts on the sequence file instance of the breakpoint -- which impacts the sequence file and all executions. Regardless of whether I initiated the modal breakpoint window with the sequence file view or any of the execution view windows open -- it always acts on the sequence file view, which means I can't use breakpoint manager to find or act on an individual breakpoint in my individual execution without impacting the sequence file view "Default" breakpoints and all other executions simultaneously.
I'd really like to see breakpoint manager improved to
1) not be modal
2) allow you to see the differences in breakpoints across the multiple views (sequence file and multiple executions)
3) be able to goto breakpoints in different views
4) be able to configure breakpoints in different views, and to be able to choose "disable only for this execution view" or "disable for all execution views but keep enabled for sequence file view" or any other logical combination of yes for these and no for those views.
5) be able to "copy" breakpoints from one view to another. -- if I've done some cool breakpoint configuration and setup just in my execution view, and I want those to be usable for the next time I run the sequence, I'm out of luck -- the next execution starts with the defaults from the sequence file view. If I could choose to "copy these breakpoint settings back to sequence file view" or "copy to this other execution view" or "synchronize all breakpoints"
6) Be able to configure breakpoints across other views -- right click on a breakpoint for step A in any view, and choose Breakpoint >> properties, and get the breakpoint manager window (or some subset of it) which allows me to see and edit the properties of that breakpoint for that specific view, but also all other views, so I can do something like create a new breakpoint in execution view #5, and then edit/manage/properties that breakpoint and choose to apply it to all other execution views and/or the sequence file view. Or any other breakpoint configuration across views.
This probably means that the treeview of breakpoint manager goes 1 layer deeper where the individual step can have breakpoint configuration that impacts all views (and the standard checkbox to enable/disable, or half-checked box to show that the settings for all children are different), but that the step node has children for all views that can be individually configured to show and enable users they can manage the independent breakpoint settings for the independent views.
Another point of confusion is that you have Debug >> Breakpoints/Wa!ches. Within that dialog you configure your breakpoints which are independent for each view, and you configure wa!ches which are NOT independent for each view (wa!ch values are different, but wa!ch expressions are identical across all execution views). The fact that this same configuration dialog handles stuff that behaves in substantially different ways just adds to the confusion. My opinion is these should be split to two different configuration dialogs unless wa!ches will be able to be managed on a per-sequence (as defaults for subsequent executions) and per-execution basis (this would be cool, but I would rank it lower on the priority list)
Thanks for the detailed feedback Warren. Wa!ch expressions actually can be set on a per execution basis. When you edit a wa!ch expression you can check the "Exist Only in Current Execution" checkbox. It's not the default though like it is with breakpoints.
Over the last few weeks the NI Community and NI Discussion Forums have experienced a series of SPAM attacks. Blocking posts with that "W" word in them is a temporary measure to cut off the posts containing SPAM links.
We're aware that, unfortunately, this measure also intercepts some legitimate posts, and we hope to remove the interceptors soon. Sorry for the inconvenience!
I just wanted to quickly let you know what's going on, so please send me a message if you have any questions.
I'm declining this idea due to a lack of community support.