Sorry for the long message.
My proposals are at the very end of this post
In order to understand the rationales I propose 2 experiments
Experiment #1:
In C:\Users\Public\Documents\National Instruments\CVI2013\samples\userint
Open 2yaxis project
Here is the code of interrest (lines 131-145):
int CVICALLBACK ScaleIt (int panel, int control, int event, void *callbackData,
int eventData1, int eventData2)
{
int val;
if (event == EVENT_COMMIT)
{
GetCtrlVal (panel, control, &val);
SetCtrlAttribute (panel, PANEL_GRAPH, ATTR_ACTIVE_YAXIS,
VAL_RIGHT_YAXIS);
SetCtrlAttribute (panel, PANEL_GRAPH, ATTR_YMAP_MODE, val);
SetActiveCtrl (panel, PANEL_GRAPH);
}
return 0;
}
Set a break point line 141 (second SetCtrlAttribute())
Then comment line 141 with 2 "/" at the beginning of the line of code
Debug the project (SHIFT+F5)
Before the code start, the breakpoint move "automatically" from line 141 to 142
Note : This is "OK". Indeed line 141 is no longer executable so it seems reasonable to move the breakpoint to the next valid line of code.
When the UIR appears, click on the scale control
Once in the editor, stop the debug session
At this point you should see the breakpoint moving automatically from line 142 to line 141
Question : Why? While the breakpoint on line 142 is enable and valid , why does the breakpoint "remember" it comes from
line 141 and then "decide" do go back on this line?
I believe it has to do with the fact that CVI try to set the environment back to the state it was before debugging the code.
IMHO this is weird.
Indeed, at the end we have a source code with a breakpoint set on a commented line.
What is the value for the user?
Experiment #2 :
If you run the same experiment but, this time, starting with a breakpoint and a comment on line 142 (last SetActiveCtrl() function call)
then the breakpoint move automatically from line 142 to line 144 (return statement)
The issue now is that the code stop on the return statement quite often and not only when the EVENT_COMMIT is managed
Based on previous experiments I would like to suggest the following
Plan A :
- During code edition, commenting a line of code which have a breakpoint CVI should disable the breakpoint (grey diamond). This provide visual information to the user.
- CVI should not try to find a new line of code where to set an active breakpoint
- Uncommenting a line which had a breakpoint CVI should NOT enable the breakpoint for the user. The breakpoint should stay grey. A single click on the grey diamond should enable the breakpoint (see another proposal I made about breakpoints)
Plan B :
- If, before execution, one breakpoint is found on a commented line
- Disable the breakpoint on the commented line (grey diamond). This provide visual information to the user.
- Try to set an new active breakpoint to the statement right after the current line of code if and only if :
a - the statement belongs to the same current block ( {.....} )
b - the condition (if any) is still valid on the selected line of code (this is already done today by CVI)
- If this is not possible, try to set an new active breakpoint to the statement right before the current line of code if and only if :
a - the statement belongs to the same current block ( {.....} )
b - the condition (if any) is still valid on the selected line of code
- Once set, even after the debugging session ends, the new active breakpoint remains active and in place
I vote for Plan B
Best regards, Philippe
)
