LabWindows/CVI Idea Exchange

Hello,

I have a table with several columns. Let's assume I want to modify properties of column 5. It would be nice if when clicking on column 5 in the UI editor this column would be preselected. Right now, the table editor opens and one has to manually select a column...

Thanks

While defining attachment mode for controls attached to a splitter we face a very strange situation. In this image you can see on the right the aspect of the window with one control selected in "Controls on the splitter" window in Attach/Detach Controls dialog. On the right the same dialog when you click on Attachment mode control:

Now, there are two strange effects:

1. Attachment mode control is being operated while dimmed 
2. If you happen to miss Attachment mode ring, you need to select again the original control in order to have the ring enabled, which is boring and time-wasting

I suggest that at least that ring is not disabled when clicking on it or clicking away from "Controls on the splitter" box.

(this suggestion refers to CVI up to 2012SP1, I cannot check it for more recent releases)

While it is possible to add, remove and replace files in a CVI project it is not possible to rename or duplicate a file.

This is useful for example if a large source code file shall be split to speed up compilation. Although this file operation could be done outside of CVI associated tags would be lost.

A workaround has been offered here but a more elegant and simple solution would be welcome. Hence I suggest to provide two more commands to add and duplicate a file including its associated tags and breakpoints...

Thanks.

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

It would be great if NI could provide standard translations of the NI runtime message file msgrte.txt in commonly-used languages.

Whilst we can get translations done ourselves, it is normally done by translators who have little knowledge of the runtime context so the quality is rather variable; also, I get the feeling that we are duplicating effort that may have been already spent elsewhere.

If it helps, I for one would be willing to pay for a decent translation.