LabWindows/CVI Idea Exchange

First of all : I LOVE the Format File and Format Selection and many thanks for the existing options in the dialog box (pointer for example)

Here is what I propose :

1 - "Function calls on single line" check box in the Miscellenaous section of the dialog box so that :

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;
}

 The code above comes from ..\CVI2013\samples\userint\2yaxis.prj

Is transformed in :

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;
}

Please note this apply not only to the SetCtrlAttribute() function call but also to the ScaleIt() function itself (very first line)
A long time ago it was OK to restrict ourselves to 80 chars per line but today I feel more confortable with statements on one line

2 - "Insert empty line before first statement in function definition" check box in the Miscellenaous section of the dialog box
Especially usefull when you use the Java Formating Option where the '{' is at the end of the line

With the previous sample code :

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;
}

The formated source (Java) should be :

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;
}

Instead of : 

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;
}

Pay attention to the "int val;" declaration with one spacing line in the first code and no spacing line in the second one.

Best regards, Philippe

To make a long story short : Breakpoints should be a kind of "3 or 4 states round-robin object" with some sort of memory regarding the condition (if any)

Let me explain...

Let start on one line with an empty margin
first click  : set breakpoint     - red diamond
second click : disable breakpoint - grey diamond
third click  : delete breakpoint  - empty margin

At this point, when the user click again and again in the margin he can see the red, grey and empty margin cyclically. Yes, 3 clicks are now needed in order to recover an empty margin (instead of 2 actually)

The behavior above ehance the existing behavior. Indeed, it gives more option to the user (disable breakpoint) without changing the way of working. In addition, it help users to discover breakpoints can be disable.

Now let's look the case where, at one point the user set a condition for the breakpoint

Again, let's start on one line with an empty margin
first click  : set breakpoint     - red diamond
right click  : edit breakpoint    - yellow rectangle (should be yellow diamond, small change in the display)
second click : disable breakpoint - grey diamond (instead of grey rectangle, this is a disable breakpoint)
third click  : delete breakpoint  - empty margin

Then, when the user click again and again in the margin he can see the red, yellow, grey diamonds and empty margin cyclically. 
Please note that the latest condition of the conditional breakpoint is set/recall automatically when the yellow diamond appears (memory effect). 

Again, the behavior above ehance the existing behavior. The key point is that you "do not loose" your condtionnal breakpoint when you click on it. I know it is not true since the breakpoint is still in the list of breakpoints but this is a frustrating experience when you click on a yellow recetangle and whe you see it "disapear".

Last but not least, overing a yellow diamond (rectangle) should display the condition in a tooltips (passcount = x - condition is : "sdfsdfsf"). I know it has been already propose and it is under consideration.

Best regards, Philippe 

Hi,

in many of my applications, I have to verifiy some conditions recursively and they can generate an error, for example when checking the presence of a file (see below).

Imagine to have a task doing this, and imagine the task is scheduled every 5 seconds or less.

This means you'll get the popup window continuosly and it makes almost impossible to debug your code.

I know I can reduce the Debugging level from Extended or Standard to No RunTime Checking in order to block that popup window, but sometime I need a deeper level of debug to fix my problems.

What do you think about adding a third button to ignore, for the current debugging session only, the run time errors generated from the same instruction?

More, what do you think about adding a fourth button to ignore, for the current debugging session only, the run time errors of the same type?

Regards

Sergio